Re:Re: Optimize crash recovery - Mailing list pgsql-hackers

From Thunder
Subject Re:Re: Optimize crash recovery
Date
Msg-id 7136498.80c4.170d4b4155a.Coremail.thunder1@126.com
Whole thread Raw
In response to Re: Optimize crash recovery  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: Re: Optimize crash recovery
List pgsql-hackers
For example, if page lsn in storage is 0x90000 and start to replay from 0x10000.
If 0x10000 is full-page xlog record, then we can ignore to replay xlog between 0x10000~0x90000 for this page.

Is there any correct issue if the page exists in the buffer pool and ignore to replay for full-page or init page if page lsn is larger than the lsn of xlog record?







At 2020-03-13 23:41:03, "Alvaro Herrera" <alvherre@2ndquadrant.com> wrote: >On 2020-Mar-13, Thunder wrote: > >> Hello hackers: >> >> >> During crash recovery, we compare most of the lsn of xlog record with page lsn to determine if the record has already been replayed. >> The exceptions are full-page and init-page xlog records. >> It's restored if the xlog record includes a full-page image of the page. >> And it initializes the page if the xlog record include init page information. >> >> >> When we enable checksum for the page and verify page success, can we >> compare the page lsn with the lsn of full-page xlog record or init >> page xlog record to detemine it has already been replayed? > >In order to verify that the checksum passes, you have to read the page >first. So what are you optimizing? > >-- >Álvaro Herrera https://www.2ndQuadrant.com/ >PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


 

pgsql-hackers by date:

Previous
From: Asif Rehman
Date:
Subject: Re: WIP/PoC for parallel backup
Next
From: Alvaro Herrera
Date:
Subject: Re: BEFORE ROW triggers for partitioned tables