Re: pg_rewind fails if there is a read only file.

From: Paul Guo <paulguo(at)gmail(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Michael Paquier <michael(at)paquier(dot)xyz>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_rewind fails if there is a read only file.
Date: 2021-05-27 13:50:28
Message-ID: CABQrizfrZRJJd0Gzo457bF-FpOHFWDyvqAvjWiwq0CPEWM2jmw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, May 26, 2021 at 10:32 PM Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>
>
> On 5/26/21 2:43 AM, Laurenz Albe wrote:
> > On Wed, 2021-05-26 at 08:57 +0900, Michael Paquier wrote:
> >> On Tue, May 25, 2021 at 03:17:37PM -0400, Andrew Dunstan wrote:
> >>> If we do decide to do something the question arises what should it do?
> >>> If we're to allow for it I'm wondering if the best thing would be simply
> >>> to ignore such a file.
> >> Enforcing assumptions that any file could be ready-only is a very bad
> >> idea, as that could lead to weird behaviors if a FS is turned as
> >> becoming read-only suddenly while doing a rewind. Another idea that
> >> has popped out across the years was to add an option to pg_rewind so
> >> as users could filter files manually. That could be easily dangerous
> >> though in the wrong hands, as one could think that it is a good idea
> >> to skip a control file, for example.
> >>
> >> The thing is that here we actually know the set of files we'd like to
> >> ignore most of the time, and we still want to have some automated
> >> control what gets filtered. So here is a new idea: we build a list of
> >> files based on a set of GUC parameters using postgres -C on the target
> >> data folder, and assume that these are safe enough to be skipped all
> >> the time, if these are in the data folder.
> > That sounds complicated, but should work.
> > There should be a code comment somewhere that warns people not to forget
> > to look at that when they add a new GUC.
> >
> > I can think of two alternatives to handle this:
> >
> > - Skip files that cannot be opened for writing and issue a warning.
> > That is simple, but coarse.
> > A slightly more sophisticated version would first check if files
> > are the same on both machines and skip the warning for those.
> >
> > - Paul's idea to try and change the mode on the read-only file
> > and reset it to the original state after pg_rewind is done.
> >
>
> How about we only skip (with a warning) read-only files if they are in
> the data root, not a subdirectory? That would save us from silently

The assumption seems to limit the user scenario.

> ignoring read-only filesystems and not involve using a GUC.

How about this:
By default, change and reset the file mode before and after open() for
read only files,
but we also allow to pass skip-file names to pg_rewind (e.g.
pg_rewind --skip filenameN or --skip-list-file listfile) in case users really
want to skip some files (probably not just read only files).
Presumably the people
who run pg_rewind should be DBA or admin that have basic knowledge of this
so we should not worry too much about that the user skips some important files
(we could even set a deny list for this). Also this solution works
fine for a read only
file system since pg_rewind soon quits when adding the write
permission for any read only file.

--
Paul Guo (Vmware)

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Paul Guo 2021-05-27 13:59:10 Re: sync request forward function ForwardSyncRequest() might hang for some time in a corner case?
Previous Message Tom Lane 2021-05-27 13:34:08 Re: Move pg_attribute.attcompression to earlier in struct for reduced size?