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
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 |
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 |