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: Markus Wanner <markus.wanner@enterprisedb.com>
Cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Date: 2022-04-05T14:01:56Z
Lists: pgsql-hackers
On Tue, Apr 5, 2022 at 9:02 AM Markus Wanner <markus.wanner@enterprisedb.com> wrote: > And for this specific case: Is it worth reverting this change and > applying a fully backwards compatible fix, instead? I think it's normally our policy to avoid changing definitions of accessible structs in back branches, except that we allow ourselves the indulgence of adding new members at the end or in padding space. So what would probably be best is if, in the back-branches, we changed "delayChkpt" back to a boolean, renamed it to delayChkptStart, and added a separate Boolean called delayChkptEnd. Maybe that could be added just after statusFlags, where I think it would fall into padding space. I think as the person who committed that patch I'm on the hook to fix this if nobody else would like to do it, but let me ask whether Kyotaro Horiguchi would like to propose a patch, since the original patch did, and/or whether you would like to propose a patch, as the person reporting the issue. -- 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