Re: pg_rewind failure by file deletion in source server

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

In response to

Responses

Browse pgsql-hackers by date

  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