Re: BUG #6425: Bus error in slot_deform_tuple

From: Duncan Rance <postgres(at)dunquino(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #6425: Bus error in slot_deform_tuple
Date: 2012-02-01 20:43:48
Message-ID: 846B8F25-A7C1-4513-A284-D496C1DFC590@dunquino.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

On 1 Feb 2012, at 18:10, Robert Haas wrote:
> I went looking for commits that might be relevant to this that are new
> in 9.0.6, also present in 9.1.2 (per 6200), and related to t_hoff, and
> came up with this one:
>
> Branch: master [039680aff] 2011-11-04 23:22:50 -0400

I looked at this and it seems specific to doing an ALTER TABLE ADD COLUMN, which we're not in this case.

I mentioned in the bug report that I has asserts in places were t_hoff is set. I've been doing it like so:

if (hoff % 4 != 0) {
elog(ERROR, "wrong hoff: %d",hoff);
abort();
}

I've been sitting here waiting for the server to abort and only just realised there are some interesting entries in my pgbench logs. I'm using pgbench to hammer the server with queries, and I have a handful of these:

Client 87 aborted in state 8: ERROR: wrong hoff: 134

I have these abort() calls in:

backend/access/common/heaptuple.c
backend/access/heap/heapam.c
backend/access/heap/tuptoaster.c

But I know from the text that it must have been from either slot_deform_tuple(), heap_form_tuple() or heap_form_minimal_tuple() in heaptuple.c.

What I don't get is why this is causing the client to abort, and not the backend.

What can I do to get the server to abort at this point? Use PANIC instead of ERROR in the elog call perhaps?

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Alvaro Herrera 2012-02-01 21:05:29 Re: BUG #6425: Bus error in slot_deform_tuple
Previous Message Alex Lai 2012-02-01 20:19:53 Re: BUG #6426: Complex query runs 10 times longer with "LIMIT 20"

Browse pgsql-hackers by date

  From Date Subject
Next Message Dimitri Fontaine 2012-02-01 21:02:14 Re: pg_dump -s dumps data?!
Previous Message Peter Eisentraut 2012-02-01 20:32:29 Re: Review of patch renaming constraints