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.
Yours,
Laurenz Albe