arssher
commented
2 months ago I have not investigated if we have a problem with logical decoding, however. Let's deal with that separately.
AFAIR we shouldn't because all WAL earlier than the first record LSN will be requested from safekeepers (neon_walreader.c).
If the primary is started at an LSN within the first of a 16 MB WAL segment, the "long XLOG page header" at the beginning of the segment was not initialized correctly. That has gone unnnoticed, because under normal circumstances, nothing looks at the page header. The WAL that is streamed to the safekeepers starts at the new record's LSN, not at the beginning of the page, so that bogus page header didn't propagate elsewhere, and a primary server doesn't normally read the WAL its written. Which is good because the contents of the page would be bogus anyway, as it wouldn't contain any of the records before the LSN where the new record is written.
Except that in the following cases a primary does read its own WAL:
When there are two-phase transactions in prepared state at checkpoint. The checkpointer reads the two-phase state from the XLOG_XACT_PREPARE record, and writes it to a file in pg_twophase/.
Logical decoding reads the WAL starting from the replication slot's restart LSN.
This PR fixes the problem with two-phase transactions. For that, it's sufficient to initialize the page header correctly. The checkpointer only needs to read XLOG_XACT_PREPARE records that were generated after the server startup, so it's still OK that older WAL is missing / bogus.
I have not investigated if we have a problem with logical decoding, however. Let's deal with that separately.