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

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
ignoring read-only filesystems and not involve using a GUC.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com