Re: Potential ABI breakage in upcoming minor releases
От | Mats Kindahl |
---|---|
Тема | Re: Potential ABI breakage in upcoming minor releases |
Дата | |
Msg-id | CA+14426oHGM1A7kMK1Sv=xYizjmdnJdWYkkud9NEgGsqbg1CCg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Potential ABI breakage in upcoming minor releases (Marco Slot <marco.slot@gmail.com>) |
Список | pgsql-hackers |
On Fri, Nov 15, 2024 at 12:51 PM Marco Slot <marco.slot@gmail.com> wrote:
On Fri, Nov 15, 2024 at 9:57 AM Aleksander Alekseev
<aleksander@timescale.com> wrote:
> I'm working with the TimescaleDB dev team to fix these issues on the
> TimescaleDB side.
I looked a bit at this out of interest. I see an assert failure in the
lines below when running tests with TimescaleDB compiled against 17.0
with 17.1 installed. Without the assertion it would anyway segfault
below.
/*
* Usually, mt_lastResultIndex matches the target rel. If it happens not
* to, we can get the index the hard way with an integer division.
*/
whichrel = mtstate->mt_lastResultIndex;
if (resultRelInfo != mtstate->resultRelInfo + whichrel)
{
whichrel = resultRelInfo - mtstate->resultRelInfo;
Assert(whichrel >= 0 && whichrel < mtstate->mt_nrels);
}
updateColnos = (List *) list_nth(node->updateColnosLists, whichrel);
The problem here is that because TimescaleDB compiled against 17.0
assumes a struct size of 376 (on my laptop) while PostgreSQL allocated
the array with a struct size of 384, so the pointer math no longer
holds and the whichrel value becomes nonsense. (1736263376 for
whatever reason)
That was one of the failures that we had, but we also have a copy of the ExecModifyTable() function and this line would in that case be a problem:
607
608 /* Preload local variables */
609 resultRelInfo = node->resultRelInfo + node->mt_lastResultIndex;
610 subplanstate = outerPlanState(node);
611
--
Best wishes,
Mats Kindahl, Timescale
В списке pgsql-hackers по дате отправления: