Re: pg_rewind failure by file deletion in source server
От | Heikki Linnakangas |
---|---|
Тема | Re: pg_rewind failure by file deletion in source server |
Дата | |
Msg-id | 5582CDC6.2070507@iki.fi обсуждение исходный текст |
Ответ на | Re: pg_rewind failure by file deletion in source server (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: pg_rewind failure by file deletion in source server
|
Список | 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
В списке pgsql-hackers по дате отправления: