Re: Potential ABI breakage in upcoming minor releases - Mailing list pgsql-hackers

From Marco Slot
Subject Re: Potential ABI breakage in upcoming minor releases
Date
Msg-id CAFMSG9Hy-2-8tfmmKy7noCbA3Yn1UY2SFUwYj7wHODTO8gDm8w@mail.gmail.com
Whole thread Raw
In response to Re: Potential ABI breakage in upcoming minor releases  (Aleksander Alekseev <aleksander@timescale.com>)
Responses Re: Potential ABI breakage in upcoming minor releases
Re: Potential ABI breakage in upcoming minor releases
List pgsql-hackers
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)

cheers,
Marco



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Potential ABI breakage in upcoming minor releases
Next
From: Maxim Orlov
Date:
Subject: Re: Improve error messages for database object stats manipulation functions during recovery