Re: API stability [was: pgsql: Fix possible recovery trouble if TRUNCATE overlaps a checkpoint.]

Markus Wanner <markus.wanner@enterprisedb.com>

From: Markus Wanner <markus.wanner@enterprisedb.com>

To: Michael Paquier <michael@paquier.xyz>, Robert Haas <robertmhaas@gmail.com>

Cc: Tom Lane <tgl@sss.pgh.pa.us>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>

Date: 2022-04-08T08:47:26Z

Lists: pgsql-hackers

Attachments

0001-Rethink-the-delay-v2.patch (text/x-patch) patch v2-0001

On Fri, 2022-04-08 at 08:47 +0900, Michael Paquier wrote:
> On Thu, Apr 07, 2022 at 11:19:15AM -0400, Robert Haas wrote:
> > Here are patches for master and v14 to do things this way.
> > Comments?
> 
> Thanks for the patches.  They look correct.

+1, looks good to me and addresses my specific original concern.

> For ~14, I'd rather avoid
> the code duplication done by GetVirtualXIDsDelayingChkptEnd() and
> HaveVirtualXIDsDelayingChkpt() that could be avoided with an extra
> bool argument to the existing routine.  The same kind of duplication
> happens with GetVirtualXIDsDelayingChkpt() and
> GetVirtualXIDsDelayingChkptEnd().

I agree with Michael, it would be nice to not duplicate the code, but
use a common underlying method.  A modified patch is attached.

Best Regards

Markus

Commits

Rethink the delay-checkpoint-end mechanism in the back-branches.
- 48b398943b78 10.21 landed
- 6270ee445040 11.16 landed
- 68e605b9ef37 12.11 landed
- d18c913b786c 13.7 landed
- 10520f434687 14.3 landed
Rename delayChkpt to delayChkptFlags.
- f37015a1617d 15.0 landed
Fix possible recovery trouble if TRUNCATE overlaps a checkpoint.
- bbace5697df1 14.3 cited