From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Markus Wanner <markus(dot)wanner(at)enterprisedb(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
Subject: | Re: API stability [was: pgsql: Fix possible recovery trouble if TRUNCATE overlaps a checkpoint.] |
Date: | 2022-04-05 14:29:03 |
Message-ID: | CA+Tgmoabm0CHEYE2HpFSopGxrJ3u0edM=Mjx==sWrpdHvQ00qQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
On Tue, Apr 5, 2022 at 10:17 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Renaming it would constitute an API break, which is if anything worse
> than an ABI break.
I don't think so, because an API break will cause a compilation
failure, which an extension author can easily fix.
> While we're complaining at you, let me point out that changing a field's
> content and semantics while not changing its name is a time bomb waiting
> to break any third-party code that looks at (or modifies...) the field.
>
> 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.
Well, we can do it that way, I suppose.
--
Robert Haas
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2022-04-05 14:32:06 | Re: API stability [was: pgsql: Fix possible recovery trouble if TRUNCATE overlaps a checkpoint.] |
Previous Message | Tom Lane | 2022-04-05 14:17:39 | Re: API stability [was: pgsql: Fix possible recovery trouble if TRUNCATE overlaps a checkpoint.] |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2022-04-05 14:32:06 | Re: API stability [was: pgsql: Fix possible recovery trouble if TRUNCATE overlaps a checkpoint.] |
Previous Message | Greg Stark | 2022-04-05 14:26:58 | Re: ExecRTCheckPerms() and many prunable partitions |