Re: Possible corruption by CreateRestartPoint at promotion

On Mon, May 09, 2022 at 09:24:06AM +0900, Michael Paquier wrote:
> Okay, applied this one on HEAD after going back-and-forth on it for
> the last couple of days.  I have found myself shaping the patch in
> what looks like its simplest form, by applying the check based on an
> older checkpoint to all the fields updated in the control file, with
> the check on DB_IN_ARCHIVE_RECOVERY applying to the addition of
> DB_SHUTDOWNED_IN_RECOVERY (got initialially surprised that this was
> having side effects on pg_rewind) and the minRecoveryPoint
> calculations.

It took me some time to make sure that this would be safe, but done
now for all the stable branches.

> Now, it would be nice to get a test for this stuff, and we are going
> to need something cheaper than what's been proposed upthread.  This
> comes down to the point of being able to put a deterministic stop
> in a restart point while it is processing, meaning that we need to
> interact with one of the internal routines of CheckPointGuts().  One
> fancy way to do so would be to forcibly take a LWLock to stuck the
> restart point until it is released.  Using a SQL function for that
> would be possible, if not artistic.  Perhaps we don't need such a
> function though, if we could stuck arbitrarily the internals of a 
> checkpoint?  Any ideas?

One thing that we could do here is to resurrect the patch that adds
support for stop points in the code..
--
Michael