On Thu, 2026-01-15 at 09:47 +0800, lchch1990@sina.cn wrote:
> I am thinking about why pg_rewind need wal_log_hints or data_checksums which significantly
> limits its usability. I research somewhere can can only find it's for against data
> corruption in code comment.
See https://postgr.es/m/CA%2BTgmoY4j%2Bp7JY69ry8GpOSMMdZNYqU6dtiONPrcxaVG%2BSPByg%40mail.gmail.com
In more detail:
1. there is a transaction open on the primary server (server A)
2. the transaction inserts a row
3. a checkpoint happens
4. the transaction commits
5. the session reads the row it just inserted, which sets hint bits on the row
that mark it as generally visible
Now the standby (server B) promoted between steps 3 and 4, which means that on server B
(the new primary), the transaction didn't commit and the row is invisible.
Now if we run pg_rewind on server A, it examines the local WAL to find all the blocks
that were modified after the last common checkpoint (which happened in step 3 above).
If neither wal_log_hints = on nor checksums are enabled (which effectively forces
WAL-logging hint bit changes), there is no track of step 5 in the WAL, and pg_rewind
fails to copy that block from server B. The consequence is that after pg_rewind, the
row is *still* visible on server A because of the hint bits. That is data corruption.
Therefore, the requirement cannot be relaxed.
Yours,
Laurenz Albe
