Horton

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

Petr Jelinek <petr.jelinek@enterprisedb.com>

View thread View on postgr.es
From: Petr Jelinek <petr.jelinek@enterprisedb.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Markus Wanner <markus.wanner@enterprisedb.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Date: 2022-04-07T18:07:17Z
Lists: pgsql-hackers 
> On 7. 4. 2022, at 17:19, Robert Haas <robertmhaas@gmail.com> wrote:
> 
> On Tue, Apr 5, 2022 at 10:17 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> What I think you need to do is:
>> 
>> 1. In the back branches, revert delayChkpt to its previous type and
>> semantics.  Squeeze a separate delayChkptEnd bool in somewhere
>> (you can't change the struct size either ...).
>> 
>> 2. In HEAD, rename the field to something like delayChkptFlags,
>> to ensure that any code touching it has to be inspected and updated.
> 
> Here are patches for master and v14 to do things this way. Comments?


Yeah I think this should do it (compilers should warn on master even without the rename, but who notices that right? :) )

Thanks,
Petr

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.