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