Re: pg_rewind failure by file deletion in source server - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: pg_rewind failure by file deletion in source server
Date
Msg-id 5582CDC6.2070507@iki.fi
Whole thread Raw
In response to Re: pg_rewind failure by file deletion in source server  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: pg_rewind failure by file deletion in source server  (Michael Paquier <michael.paquier@gmail.com>)
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: Inheritance planner CPU and memory usage change since 9.3.2
Next
From: Tom Lane
Date:
Subject: Re: "could not adopt C locale" failure at startup on Windows