From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_rewind failure by file deletion in source server |
Date: | 2015-06-18 13:55:18 |
Message-ID: | 5582CDC6.2070507@iki.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 06/16/2015 02:04 AM, Michael Paquier wrote:
> In order to reduce the risk of failure to a minimum and to preserve
> the performance of the tool when using --source-server, I think that
> we should add some check using pg_stat_file to see if a file is still
> present or not, and if it is missing we can safely skip it thanks to
> minRecoveryPoint. Now the problem is that pg_stat_file fails
> automatically if the file targeted is missing. Hence, to avoid a bunch
> of round trips with the server with one call to pg_stat_dir per file,
> I think that we should add some if_not_exists option to pg_stat_file,
> defaulting to false, to skip the error related to the file missing and
> have it return NULL in this case. Then we could use this filter on the
> file path in libpq_executeFileMap() to fetch only the file chunks that
> actually exist on the server.
You'll also need to add the option to pg_read_binary_file, though,
because even if you do a test with pg_stat_file() just before reading
the file, there's a race condition: someone might still delete file
between pg_stat_file() and pg_read_file().
Listing the directories with pg_ls_dir() has the same problem. As does
pg_tablespace_location().
> Note that we could as well use some plpgsql-ing to do the same, but
> the extension of pg_stat_file looks more useful to me. Thoughts?
Hmm. You'll need to add the option to all of those functions. Maybe it's
nevertheless the simplest approach.
- Heikki
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2015-06-18 14:31:55 | Re: "could not adopt C locale" failure at startup on Windows |
Previous Message | Robert Haas | 2015-06-18 13:48:38 | Re: Inheritance planner CPU and memory usage change since 9.3.2 |