Re: BUG #6425: Bus error in slot_deform_tuple
От | Tom Lane |
---|---|
Тема | Re: BUG #6425: Bus error in slot_deform_tuple |
Дата | |
Msg-id | 5101.1328219790@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #6425: Bus error in slot_deform_tuple (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #6425: Bus error in slot_deform_tuple
|
Список | 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 по дате отправления: