Horton

Re: BUG #18815: Logical replication worker Segmentation fault

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Tomas Vondra <tomas@vondra.me>
Cc: Sergey Belyashov <sergey.belyashov@gmail.com>, pgsql-bugs@lists.postgresql.org
Date: 2025-02-17T20:13:00Z
Lists: pgsql-bugs, 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. Fix uninitialized index information access during apply.

  2. Assert that ExecOpenIndices and ExecCloseIndices are not repeated.

  3. Fix crash in brininsertcleanup during logical replication.

I wrote:
> I suspect that the attached will fix it.  What I don't understand
> is why it's apparently so hard to trigger the crash, because it
> looks to me like any two successive insert commands on the same
> BRIN index should hit this.

Oh, wait: I was confusing ii_AmCache with rd_amcache in the index's
relcache entry.  This coding would absolutely not work with rd_amcache
since that's persistent.  It mostly works with the IndexInfo field
though, since an IndexInfo typically only survives per-query.
Evidently there's some path in logical replication that will re-use an
IndexInfo across multiple distinct insertion operations, and that's
what breaks it.

> BTW, I'm also a bit suspicious of the comment's claim that the
> brinDesc doesn't need cleanup.  That looks like a potential
> memory leak.

This concern still stands.

			regards, tom lane