Re: Data-only pg_rewind, take 2 - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: Data-only pg_rewind, take 2
Date
Msg-id 20190318063219.GH6197@tamriel.snowman.net
Whole thread Raw
In response to Re: Data-only pg_rewind, take 2  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
Greetings,

* Michael Paquier (michael@paquier.xyz) wrote:
> On Sun, Mar 17, 2019 at 09:00:57PM +0800, Chris Travers wrote:
> > I also added test cases and some docs.  I don't know if the docs are
> > sufficient.  Feedback is appreciated.
>
> To be honest, I don't think that this approach is a good idea per the
> same reasons as mentioned the last time, as this can cause pg_rewind
> to break if any newly-added folder in the data directory has
> non-replaceable data which is needed at the beginning of recovery and
> cannot be automatically rebuilt.  So that's one extra maintenance
> burden to worry about.

The right approach to deal with that is to have a canonical list of
those, isn't it?  So that we have one place to update that takes care to
make sure that all of the tools realize what's actually needed.

In general, I agree completely with Chris on the reasoning behind this
patch and that we really should try to avoid copying random files and
directories that have shown up in the data directory during a pg_rewind.
Having regular expressions and other such things just strike me as a
really bad idea for a low-level tool like pg_rewind- if users have
dropped other stuff in the data directory that they want copied around
between systems then it should be on them to make that happen, not
expect pg_rewind to copy them..

Thanks!

Stephen

Attachment

pgsql-hackers by date:

Previous
From: Kyotaro HORIGUCHI
Date:
Subject: Re: Unaccent extension python script Issue in Windows
Next
From: Stephen Frost
Date:
Subject: Re: Online verification of checksums