Re: BUG #6425: Bus error in slot_deform_tuple - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #6425: Bus error in slot_deform_tuple
Date
Msg-id 5101.1328219790@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #6425: Bus error in slot_deform_tuple  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: BUG #6425: Bus error in slot_deform_tuple
List pgsql-bugs
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

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #6425: Bus error in slot_deform_tuple
Next
From: Steven Schlansker
Date:
Subject: Re: [JDBC] BUG #6293: JDBC driver performance