Re: Possible corruption by CreateRestartPoint at promotion - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Possible corruption by CreateRestartPoint at promotion
Date
Msg-id YnT/Y2sEYj7pyOdc@paquier.xyz
Whole thread Raw
In response to Re: Possible corruption by CreateRestartPoint at promotion  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Possible corruption by CreateRestartPoint at promotion  (Michael Paquier <michael@paquier.xyz>)
Re: Possible corruption by CreateRestartPoint at promotion  (Nathan Bossart <nathandbossart@gmail.com>)
List pgsql-hackers
On Thu, Apr 28, 2022 at 03:49:42PM +0900, Michael Paquier wrote:
> I am not sure what you mean here.  FWIW, I am translating the
> suggestion of Nathan to split the existing check in
> CreateRestartPoint() that we are discussing here into two if blocks,
> instead of just one:
> - Move the update of checkPoint and checkPointCopy into its own if
> block, controlled only by the check on
> (ControlFile->checkPointCopy.redo < lastCheckPoint.redo)
> - Keep the code updating minRecoveryPoint and minRecoveryPointTLI
> mostly as-is, but just do the update when the control file state is
> DB_IN_ARCHIVE_RECOVERY.  Of course we need to keep the check on
> (minRecoveryPoint < lastCheckPointEndPtr).

And I have spent a bit of this stuff to finish with the attached.  It
will be a plus to get that done on HEAD for beta1, so I'll try to deal
with it on Monday.  I am still a bit stressed about the back branches
as concurrent checkpoints are possible via CreateCheckPoint() from the
startup process (not the case of HEAD), but the stable branches will
have a new point release very soon so let's revisit this choice there
later.  v6 attached includes a TAP test, but I don't intend to include
it as it is expensive.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: strange slow query - lost lot of time somewhere
Next
From: Michael Paquier
Date:
Subject: Re: Fix typo in code comment - origin.c