Duncan Rance <postgres(at)dunquino(dot)com> writes:
> 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

Yowza.  Is this just the standard pgbench test, or something else?
If you could post complete instructions for duplicating this, we
could probably find the cause fairly quickly.

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

As Alvaro said, it's not reaching the abort().  You should use PANIC
instead.

			regards, tom lane

In response to

• Re: BUG #6425: Bus error in slot_deform_tuple at 2012-02-01 20:43:48 from Duncan Rance

Responses

• Re: BUG #6425: Bus error in slot_deform_tuple at 2012-02-01 22:37:32 from Duncan Rance

pgsql-hackers by date

Next:	From: Jim Nasby	Date: 2012-02-01 22:12:58
	Subject: Re: Progress on fast path sorting, btree index creation time
Previous:	From: Alvaro Herrera	Date: 2012-02-01 21:05:29
	Subject: Re: BUG #6425: Bus error in slot_deform_tuple

pgsql-bugs by date

Next:	From: Tom Lane	Date: 2012-02-01 21:48:35
	Subject: Re: BUG #6426: Complex query runs 10 times longer with "LIMIT 20"
Previous:	From: Tom Lane	Date: 2012-02-01 21:06:27
	Subject: Re: BUG #6200: standby bad memory allocations on SELECT