From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-07 14:04:20 |
Message-ID: | CA+TgmoZjuD7fEKakMGD-5UL4frdEq_rexwG9DnqV+7ctyJxO7A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
On Thu, Apr 7, 2022 at 2:28 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> > 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?
I don't think that commit changed sizeof(PGPROC), but it did affect
the position of the delayChkpt and statusFlags members within the
struct, which is what we now need to fix. Since I don't hear anyone
else volunteering to take care of that, I'll go work on it.
--
Robert Haas
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2022-04-07 14:24:42 | pgsql: Unlogged sequences |
Previous Message | Tom Lane | 2022-04-07 13:53:43 | Re: pgsql: Prefetch data referenced by the WAL, take II. |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2022-04-07 14:05:15 | Re: Extensible Rmgr for Table AMs |
Previous Message | Robert Haas | 2022-04-07 14:01:09 | Re: Preventing indirection for IndexPageGetOpaque for known-size page special areas |