We ran into a segmentation fault using peek_changes that appears identical
with what is described in this unfinished thread. We are running pg 10.3,
and the segfault was fixed by us upgrading to 10.6. However, we could not
find any clearly related fixes in any of the release notes for 10.4-6
relating to this bug fix. I did find this commit that I believe fixes the
issue:
https://github.com/postgres/postgres/commit/bba8c612117416907f332fce8b9e80b748e0b798
If this indeed fixes a critical issue as we think it does, could someone
please add it in the right place to the release notes?
Would it be useful to anyone for us to provide any more diagnostics for how
we encountered this bug? I have a core dump and stack trace. We
encountered it during a peek_changes being run and fetched via a cursor.
The same peek_changes from the same LSN actually succeeds after recovery.
specinsert is null here:
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x000000000084a914 in ReorderBufferCommit (rb=0x1e236c0, xid=316524727,
commit_lsn=9825880784664, end_lsn=9825880787976,
commit_time=603381553004372, origin_id=0, origin_lsn=0) at
reorderbuffer.c:1395
1395 Assert(specinsert->data.tp.oldtuple == NULL);
Some interesting notes are that we are doing INSERT ON CONFLICT UPDATE (we
are not using DO NOTHING), and the table of interest has a btree gist index.
I am certain that the decoding of this SQL process is somehow related to
this segfault.
Another note of interest is that we have been decoding using pglogical from
this system for some time with no issues, so this is definitely unique to
the use of the peek_changes function.
Please advise, thanks!
--
Sent from: http://www.postgresql-archive.org/PostgreSQL-bugs-f2117394.html
