Re: Potential ABI breakage in upcoming minor releases

Marco Slot <marco.slot@gmail.com>

From: Marco Slot <marco.slot@gmail.com>
To: Aleksander Alekseev <aleksander@timescale.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>, 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-15T11:50:35Z
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.

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