On Thu, 2026-01-15 at 09:47 +0800, [email protected] 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
