pg_rewind WAL segments deletion pitfall

Polina Bungina <bungina@gmail.com>

From: Полина Бунгина <bungina@gmail.com>
To: pgsql-bugs@lists.postgresql.org
Date: 2022-08-23T15:46:30Z
Lists: pgsql-bugs, pgsql-hackers

Attachments

Hello,

It seems for me that there is currently a pitfall in the pg_rewind
implementation.

Imagine the following situation:


There is a cluster consisting of a primary with the following
configuration: wal_level=‘replica’, archive_mode=‘on’ and a replica.

   1. The primary that is not fast enough in archiving WAL segments (e.g.
   network issues, high CPU/Disk load...)
   2. The primary fails
   3. The replica is promoted
   4. We are not lucky enough, the new and the old primary’s timelines
   diverged, we need to run pg_rewind
   5. We are even less lucky: the old primary still has some WAL segments
   with .ready signal files that were generated before the point of divergence
   and were not archived. (e.g. 000000020004D20200000095.done,
   000000020004D20200000096.ready, 000000020004D20200000097.ready,
   000000020004D20200000098.ready)
   6. The promoted primary runs for some time and recycles the old WAL
   segments.
   7. We revive the old primary and try to rewind it
   8. When pg_rewind finished successfully, we see that the WAL segments
   with .ready files are removed, because they were already absent on the
   promoted replica. We end up in a situation where we completely lose some
   WAL segments, even though we had a clear sign that they were not
archived and
   more importantly, pg_rewind read these segments while collecting
   information about the data blocks.
   9. The old primary fails to start because of the missing WAL segments
   (more strictly, the records between the last common checkpoint and the
   point of divergence) with the following log record: "ERROR:  requested WAL
   segment 000000020004D20200000096 has already been removed"


In this situation, after pg_rewind:
archived:

000000020004D20200000095

000000020004D20200000099.partial

000000030004D20200000099


the following segments are lost:

000000020004D20200000096

000000020004D20200000097

000000020004D20200000098


Thus, my thoughts are: why can’t pg_rewind be a little bit wiser in terms
of creating filemap for WALs? Can it preserve the WAL segments that contain
those potentially lost records (> the last common checkpoint and  < the
point of divergence) on the target? (see the patch attached)


If I am missing something however, please correct me or explain why it is
not possible to implement this straightforward solution.


Thank you,

Polina Bungina

Commits

  1. Fix newly introduced 010_keep_recycled_wals.pl

  2. Avoid deleting critical WAL segments during pg_rewind