Horton

Re: Potential ABI breakage in upcoming minor releases

Pavan Deolasee <pavan.deolasee@gmail.com>

View thread
From: Pavan Deolasee <pavan.deolasee@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Noah Misch <noah@leadboat.com>, Christoph Berg <myon@debian.org>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2024-11-15T03:05:48Z
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 1:00 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Noah Misch <noah@leadboat.com> writes:
> > It's not immediately to clear to me why this would crash in a non-asserts
> > build.  palloc issues a 512-byte chunk for sizeof(ResultRelInfo)==368 on
> v16,
> > so I expect no actual writing past the end of the chunk.
>
> I'm confused too.  The allocation should be big enough.  The other
> hazard would be failing to initialize the field, but if the extension
> uses InitResultRelInfo then that's taken care of.
>

I should have mentioned in my original post that our limited PGD tests are
passing too. But I wasn't sure if the problem may hit us in the field,
given the subtleness of the memory corruption. But it's quite comforting to
read Noah's analysis about why this could be a non-issue for non-assert
builds.

Thanks,
Pavan