On Wed, Sep 13, 2017 at 07:39:31PM +0200, Michael Banck wrote: > On Tue, Sep 12, 2017 at 07:38:40PM -0400, Stephen Frost wrote: > > Further, really, I think we should provide a utility to do all of the > > above instead of using rsync- and that utility should do some additional > > things, such as: > > > > - Check that the control file on the primary and replica show that they > > reached the same point prior to the pg_upgrade. If they didn't, then > > things could go badly as there's unplayed WAL that the primary got > > through and the replica didn't. > > > > - Not copy over unlogged data, or any other information that shouldn't > > be copied across. > > > > - Allow the directory structures to be more different between the > > primary and the replica than rsync allows (wouldn't have to have a > > common subdirectory on the replica). > > > > - Perhaps other validation checks or similar. > > > > Unfortunately, this is a bit annoying as it necessairly involves running > > things on both the primary and the replica from the same tool, without > > access to PG, meaning we'd have to work through something else (such as > > SSH, like rsync does, but then what would we do for Windows...?). > > Maybe pg_rewind's mechanism could be partially reused for this as it > seems to accomplish something vaguely similar AIUI?
pg_rewind works at the WAL level while this is at the file system level. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
