On Tue, Oct 17, 2023 at 12:45:52PM -0400, Robert Haas wrote:
> On Fri, Oct 13, 2023 at 3:29 AM Michael Paquier <michael@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/B2PW@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