I wrote:
> So far no luck reproducing any issue with this test case.
And I swear my finger had barely left the "send" key when:
TRAP: FailedAssertion("!(((lpp)->lp_flags == 1))", File: "heapam.c", Line: 735)
LOG: server process (PID 24740) was terminated by signal 6: Aborted
DETAIL: Failed process was running: SELECT * FROM repro_02_ref;
LOG: terminating any other active server processes
So:
(1) no need to worry about GUC settings. It's just a shade less
probable than I'd supposed from your message.
(2) I suspect you are not running with asserts enabled. You might
have better luck isolating this if they were on.
I have not gotten very far with the coredump, except to observe that
gdb says the Assert ought to have passed:
(gdb) f 3
#3 0x0000000000475248 in heapgettup_pagemode (scan=0x1457b08,
dir=<optimized out>, nkeys=0, key=0x0) at heapam.c:735
735 Assert(ItemIdIsNormal(lpp));
(gdb) p lpp
$1 = (ItemIdData *) 0x7fea59705d90
(gdb) p *lpp
$2 = {lp_off = 7936, lp_flags = 1, lp_len = 34}
This suggests very strongly that indeed the buffer was changing under
us.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
