Re: API stability [was: pgsql: Fix possible recovery trouble if TRUNCATE overlaps a checkpoint.]
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Michael Paquier <michael@paquier.xyz>,
Markus Wanner <markus.wanner@enterprisedb.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>,
Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Date: 2022-04-08T02:19:35Z
Lists: pgsql-hackers
On Thu, Apr 7, 2022 at 7:52 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Michael Paquier <michael@paquier.xyz> writes: > > 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. 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. > > Isn't adding another argument an API break? (If there's any outside > code calling GetVirtualXIDsDelayingChkpt, which it seems like there > might be.) Yeah, that's exactly why I didn't do what Michael proposes. If we're going to go to this trouble to avoid changing the layout of a PGPROC, we must be doing that on the theory that extension code cares about delayChkpt. And if that is so, it seems reasonable to suppose that it might also want to call the associated functions. Honestly, I wouldn't have thought that this mattered, because I wouldn't have guessed that any non-core code cared about delayChkpt. But I would have been wrong. -- Robert Haas EDB: http://www.enterprisedb.com
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