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

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: API stability [was: pgsql: Fix possible recovery trouble if TRUNCATE overlaps a checkpoint.]
Дата
Msg-id CA+TgmoZjuD7fEKakMGD-5UL4frdEq_rexwG9DnqV+7ctyJxO7A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: API stability [was: pgsql: Fix possible recovery trouble if TRUNCATE overlaps a checkpoint.]  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-hackers
On Thu, Apr 7, 2022 at 2:28 AM Michael Paquier <michael@paquier.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Preventing indirection for IndexPageGetOpaque for known-size page special areas
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Extensible Rmgr for Table AMs