Horton

Re: Potential ABI breakage in upcoming minor releases

Aleksander Alekseev <aleksander@timescale.com>

View thread
From: Aleksander Alekseev <aleksander@timescale.com>
To: pgsql-hackers <pgsql-hackers@postgresql.org>
Cc: Marco Slot <marco.slot@gmail.com>, Noah Misch <noah@leadboat.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, Tom Lane <tgl@sss.pgh.pa.us>, Christoph Berg <myon@debian.org>, Pavan Deolasee <pavan.deolasee@gmail.com>
Date: 2024-11-15T12:03:21Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Undo unintentional ABI break in struct ResultRelInfo.

  2. For inplace update durability, make heap_update() callers wait.

  3. Fix btmarkpos/btrestrpos array key wraparound bug.

  4. Fix calculation of which GENERATED columns need to be updated.

Hi Macro,

> 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)

Thanks for reporting. Yes, the code assumed fixed
sizeof(ResultRelInfo) within a given PG major release branch which
turned out not to be the case. We will investigate whether it can be
easily fixed on TimescaleDB side.

-- 
Best regards,
Aleksander Alekseev