From: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: New WAL record to detect the checkpoint redo location |
Date: | 2023-08-17 07:41:50 |
Message-ID: | CAFiTN-sowusTX2D3NFmZN-cc00YKdCJ06TFFse4xUMwKrLB2CA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Aug 17, 2023 at 10:52 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Tue, Aug 15, 2023 at 02:23:43PM +0530, Dilip Kumar wrote:
> > Yeah, good idea, actually we can do this insert outside of the
> > exclusive insert lock and set the LSN of this insert as the
> > checkpoint. redo location. So now we do not need to compute the
> > checkpoint. redo based on the current insertion point we can directly
> > use the LSN of this record. I have modified this and I have also
> > moved some other code that is not required to be inside the WAL
> > insertion lock.
>
> Looking at this patch, I am bit surprised to see that the redo point
> maps with the end location of the CHECKPOINT_REDO record as it is the
> LSN returned by XLogInsert(), not its start LSN.
Yeah right, actually I was confused, I assumed it will return the
start LSN of the record. And I do not see any easy way to identify
the Start LSN of this record so maybe this solution will not work. I
will have to think of something else. Thanks for pointing it out.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Smith | 2023-08-17 08:09:31 | Re: pg_upgrade - typo in verbose log |
Previous Message | Masahiro Ikeda | 2023-08-17 07:37:22 | Re: WIP: new system catalog pg_wait_event |