On Tue, Oct 17, 2023 at 12:45:52PM -0400, Robert Haas wrote: > On Fri, Oct 13, 2023 at 3:29 AM Michael Paquier <mich...@paquier.xyz> wrote: >> I've mentioned as well a test in pg_walinspect after one of the >> checkpoints generated there, but what you do here is enough for the >> online case. > > I don't quite understand what you're saying here. If you're suggesting > a potential improvement, can you be a bit more clear and explicit > about what the suggestion is?
Suggestion is from here, with a test for pg_walinspect after it runs its online checkpoint (see the full-page case): https://www.postgresql.org/message-id/ZOvf1tu6rfL/b...@paquier.xyz +-- Check presence of REDO record. +SELECT redo_lsn FROM pg_control_checkpoint() \gset +SELECT start_lsn = :'redo_lsn'::pg_lsn AS same_lsn, record_type + FROM pg_get_wal_record_info(:'redo_lsn'); >> Then repeat this pattern for non-shutdown checkpoints a few lines down >> without touching the copy of the redo LSN in XLogCtl->Insert, because >> of course we don't hold the WAL insert locks in an exclusive fashion >> here: >> checkPoint.redo = RedoRecPtr; >> >> My point is that this is not only about RedoRecPtr, but also about >> XLogCtl->Insert.RedoRecPtr here. The comment in ReserveXLogSwitch() >> says that. > > I have adjusted the comment in CreateCheckPoint to hopefully address > this concern. - * XLogInsertRecord will have updated RedoRecPtr, but we need to copy - * that into the record that will be inserted when the checkpoint is - * complete. + * XLogInsertRecord will have updated XLogCtl->Insert.RedoRecPtr in + * shared memory and RedoRecPtr in backend-local memory, but we need + * to copy that into the record that will be inserted when the + * checkpoint is complete. This comment diff between v8 and v9 looks OK to me. Thanks. > I don't understand what you mean about > ReserveXLogSwitch(), though. I am not sure either, looking back at that :p -- Michael
signature.asc
Description: PGP signature
