From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Duncan Rance <postgres(at)dunquino(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #6425: Bus error in slot_deform_tuple |
Date: | 2012-02-01 21:43:34 |
Message-ID: | 24434.1328132614@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2012-02-01 21:48:35 | Re: BUG #6426: Complex query runs 10 times longer with "LIMIT 20" |
Previous Message | Tom Lane | 2012-02-01 21:06:27 | Re: BUG #6200: standby bad memory allocations on SELECT |
From | Date | Subject | |
---|---|---|---|
Next Message | Jim Nasby | 2012-02-01 22:12:58 | Re: Progress on fast path sorting, btree index creation time |
Previous Message | Alvaro Herrera | 2012-02-01 21:05:29 | Re: BUG #6425: Bus error in slot_deform_tuple |