As discussed [1 ][2] currently, the checkpoint-redo LSN can not be accurately detected while processing the WAL. Although we have a checkpoint WAL record containing the exact redo LSN, other WAL records may be inserted between the checkpoint-redo LSN and the actual checkpoint record. If we want to stop processing wal exactly at the checkpoint-redo location then we cannot do that because we would have already processed some extra records that got added after the redo LSN.
The patch inserts a special wal record named CHECKPOINT_REDO WAL, which is located exactly at the checkpoint-redo location. We can guarantee this record to be exactly at the checkpoint-redo point because we already hold the exclusive WAL insertion lock while identifying the checkpoint redo point and can insert this special record exactly at the same time so that there are no concurrent WAL insertions. [1] https://www.postgresql.org/message-id/CA%2BTgmoYOYZfMCyOXFyC-P%2B-mdrZqm5pP2N7S-r0z3_402h9rsA%40mail.gmail.com [2] https://www.postgresql.org/message-id/20230614194717.jyuw3okxup4cvtbt%40awork3.anarazel.de -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
v1-0001-New-WAL-record-to-identify-check-redo-location.patch
Description: Binary data