Re: New WAL record to detect the checkpoint redo location

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

In response to

Responses

Browse pgsql-hackers by date

  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