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  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: BUG #6425: Bus error in slot_deform_tuple
Следующее
От: Steven Schlansker
Дата:
Сообщение: Re: [JDBC] BUG #6293: JDBC driver performance