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?
