On Fri, May 06, 2022 at 07:58:43PM +0900, Michael Paquier wrote: > 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.
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. 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? -- Michael
signature.asc
Description: PGP signature
