Re: API stability [was: pgsql: Fix possible recovery trouble if TRUNCATE overlaps a checkpoint.]
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>, Markus Wanner <markus.wanner@enterprisedb.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Date: 2022-04-07T06:28:19Z
Lists: pgsql-hackers
On Tue, Apr 05, 2022 at 03:16:20PM -0400, Tom Lane wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Tue, Apr 5, 2022 at 10:32 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> My point is that we want that to happen in HEAD, but it's not okay >>> for it to happen in a minor release of a stable branch. > >> I understand, but I am not sure that I agree. I think that if an >> extension stops compiling against a back-branch, someone will notice >> the next time they try to compile it and will fix it. Maybe that's not >> amazing, but I don't think it's a huge deal either. I agree with Tom's argument. The internals of this structure should not have changed in a stable branch. > Well, perhaps it's not the end of the world, but it's still a large > PITA for the maintainer of such an extension. They can't "just fix it" > because some percentage of their userbase will still need to compile > against older minor releases. Nor have you provided any way to handle > that requirement via conditional compilation. For example, I recall that some external extensions make use of sizeof(PGPROC) for their own business. Isn't 412ad7a going to be a problem to change this structure's internals for already-compiled code on stable branches? -- Michael
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