Horton

Re: Refactor pg_rewind code and make it work against a standby

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Soumyadeep Chakraborty <soumyadeep2007@gmail.com>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2020-11-20T17:14:20Z
Lists: pgsql-hackers 
Hi,

On 2020-11-20 16:19:03 +0200, Heikki Linnakangas wrote:
> Pushed a fix similar to your patch, but I put the wait_for_catchup() before
> running pg_rewind. The point of inserting the 'in A, after C was promoted'
> row is that it's present in B when pg_rewind runs.

Hm - don't we possibly need *both*? Since post pg_rewind recovery starts
at the previous checkpoint, it's quite possible for C to get ready to
answer queries before that record has been replayed?

Thanks,

Andres Freund

Commits

  1. Make pg_rewind test case more stable.

  2. Fix timing issue in pg_rewind test.

  3. Allow pg_rewind to use a standby server as the source system.

  4. pg_rewind: Refactor the abstraction to fetch from local/libpq source.

  5. pg_rewind: Replace the hybrid list+array data structure with simplehash.

  6. Refactor pg_rewind for more clear decision making.

  7. pg_rewind: Move syncTargetDirectory() to file_ops.c