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

  1. Rethink the delay-checkpoint-end mechanism in the back-branches.

  2. Rename delayChkpt to delayChkptFlags.

  3. Fix possible recovery trouble if TRUNCATE overlaps a checkpoint.