Horton

Re: Potential ABI breakage in upcoming minor releases

Gregory Smith <gregsmithpgsql@gmail.com>

View thread
From: Gregory Smith <gregsmithpgsql@gmail.com>
To: noah@leadboat.com
Cc: 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>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2024-11-15T00:01:42Z
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 Thu, Nov 14, 2024 at 5:41 PM Noah Misch <noah@leadboat.com> wrote:

> I'm hearing the only confirmed impact on non-assert builds is the need to
> recompile timescaledb.  (It's unknown whether recompiling will suffice for
> timescaledb.  For assert builds, six PGXN extensions need recompilation.)
>

That matches what our build and test teams are seeing.

We dug into the two lines of impacted Citus code, they are just touching
columnar metadata.  We dragged Marco into a late night session to double
check that with the Citus columnar regression tests and look for red flags
in the code.  In an assert Citus built against 16.4 running against
PostgreSQL 16.5, he hit the assert warnings, but the tests pass and there's
no signs or suspicion of a functional impact:

CREATE TABLE columnar_table_1 (a int) USING columnar;
INSERT INTO columnar_table_1 VALUES (1);
+WARNING:  problem in alloc set Stripe Write Memory Context: detected write
past chunk end in block 0x563ee43a4f10, chunk 0x563ee43a6240
+WARNING:  problem in alloc set Stripe Write Memory Context: detected write
past chunk end in block 0x563ee4369bb0, chunk 0x563ee436acb0
+WARNING:  problem in alloc set Stripe Write Memory Context: detected write
past chunk end in block 0x563ee4369bb0, chunk 0x563ee436b3c8

Thanks to everyone who's jumped in to investigate here.  With the PL/Perl
CVE at an 8.8, sorting out how to get that fix to everyone and navigate the
breakage is very important.

--
Greg Smith, Crunchy Data
Director of Open Source Strategy