Re: BUG #18815: Logical replication worker Segmentation fault

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Tomas Vondra <tomas(at)vondra(dot)me>
Cc: Sergey Belyashov <sergey(dot)belyashov(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #18815: Logical replication worker Segmentation fault
Date: 2025-02-17 20:13:00
Message-ID: 911898.1739823180@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Jose Fco. Mojada 2025-02-17 20:16:51 Re: Possible bug ¿? missing "ucol.h" in postgre installation
Previous Message Tom Lane 2025-02-17 19:47:19 Re: Possible bug ¿? missing "ucol.h" in postgre installation

Browse pgsql-hackers by date

  From Date Subject
Next Message Jelte Fennema-Nio 2025-02-17 20:25:33 Re: Bump soft open file limit (RLIMIT_NOFILE) to hard limit on startup
Previous Message Masahiko Sawada 2025-02-17 20:07:56 Re: POC: enable logical decoding when wal_level = 'replica' without a server restart