public inbox for [email protected]
help / color / mirror / Atom feedFrom: Michael Paquier <[email protected]>
To: Robert Haas <[email protected]>
Cc: Andres Freund <[email protected]>
Cc: Dilip Kumar <[email protected]>
Cc: Heikki Linnakangas <[email protected]>
Cc: pgsql-hackers <[email protected]>
Subject: Re: New WAL record to detect the checkpoint redo location
Date: Wed, 18 Oct 2023 09:35:17 +0900
Message-ID: <[email protected]> (raw)
In-Reply-To: <CA+Tgmoar8fD7tocgauu6xtFF5HEwK-dBqoTKEGeDBA8Prv=fkQ@mail.gmail.com>
References: <[email protected]>
<CA+TgmoYy-Vc6G9QKcAKNksCa29cv__czr+N9X_QCxEfQVpp_8w@mail.gmail.com>
<CA+TgmoZ_C1DKuNT0w13_b_6J8JgSupHFSLBCKgQdhJf3FannbA@mail.gmail.com>
<CA+TgmoZAM24Ub=uxP0aWuWstNYTUJQ64j976FYJeVaMJ+qD0uw@mail.gmail.com>
<[email protected]>
<CA+Tgmob90XtBJ+WdSHA+y8ZikHPSxQvZwYDefEBLC7Bkwx=3-g@mail.gmail.com>
<[email protected]>
<CA+TgmoaaMge7NNBE45kSWz9HkgbSoe9mwicOuOOxLAkb6i2JdQ@mail.gmail.com>
<[email protected]>
<CA+Tgmoar8fD7tocgauu6xtFF5HEwK-dBqoTKEGeDBA8Prv=fkQ@mail.gmail.com>
On Tue, Oct 17, 2023 at 12:45:52PM -0400, Robert Haas wrote:
> On Fri, Oct 13, 2023 at 3:29 AM Michael Paquier <[email protected]> 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/[email protected]
+-- 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
Attachments:
[application/pgp-signature] signature.asc (833B, ../[email protected]/2-signature.asc)
download
view thread (13+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: New WAL record to detect the checkpoint redo location
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox