Thread: some pg_rewind usability issues
pg_rewind --source-server uses the libpq default mechanisms for the database, but that's useless for pg_rewind, which can just always use dbname=postgres, like other database-agnostic utilities. pg_rewind requires that the target server be shut down cleanly, but does not accept shutdown in recovery. Is that necessary? I have been trying to come with a kind of typical workflow for this tool, which goes something like this: - have a target server that I'd like to reattach to a new source server - write recovery.conf file - start target server; sometimes this works without pg_rewind -> happy - otherwise run pg_rewind, which fails because of shutdown in recovery - remove recovery.conf, start server, stop server - run pg_rewind again - put back recovery.conf - start server If I patch pg_rewind to allow shutdown in recovery, it goes slightly easier, but it will delete my recovery.conf file and instead copy over the recovery.done file from the other guy, which can lead to some confusion. Could we change this to: - not delete recovery.conf - not copy recovery.done ?
On Wed, Sep 16, 2015 at 10:28 PM, Peter Eisentraut <peter_e@gmx.net> wrote: > pg_rewind --source-server uses the libpq default mechanisms for the > database, but that's useless for pg_rewind, which can just always use > dbname=postgres, like other database-agnostic utilities. Keep in mind that the postgres database can be dropped. Most if not all of our other utilities offer a Way Out in that situation. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Wed, Sep 16, 2015 at 7:28 PM, Peter Eisentraut <peter_e@gmx.net> wrote: > pg_rewind requires that the target server be shut down cleanly, but does > not accept shutdown in recovery. Is that necessary? > [blah] > If I patch pg_rewind to allow shutdown in recovery, it goes slightly > easier, but it will delete my recovery.conf file and instead copy over > the recovery.done file from the other guy, which can lead to some confusion. That's something that we discussed in this CF's patch to ease the handling of timeline switches when rewinding a node, I wouldn't have any objection to get that backpatched to 9.5 though (the DB_SHUTDOWNED_IN_RECOVERY part I mean). > Could we change this to: > - not delete recovery.conf > - not copy recovery.done > ? The implementation of pg_rewind took the direction of not having any filtering routines when comparing the source and target files to simplify the implementation (there are actually many similar things with what pg_basebackup needs so we'd better perhaps have a common API for both things in say src/common if we take that direction), user needing to copy by himself in an external path any configuration files that he needs back in the target's PGDATA. -- Michael
On Wed, Sep 16, 2015 at 9:46 PM, Michael Paquier wrote: > That's something that we discussed in this CF's patch to ease the > handling of timeline switches when rewinding a node, I wouldn't have > any objection to get that backpatched to 9.5 though (the > DB_SHUTDOWNED_IN_RECOVERY part I mean). Independent patch attached FWIW (I'm sure you had the same though). -- Michael