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:
>=20
> 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 s=
et. I've been doing it like so:
if (hoff % 4 !=3D 0) {
elog(ERROR, "wrong hoff: %d",hoff);
abort();
}
I've been sitting here waiting for the server to abort and only just realis=
ed 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_tup=
le(), 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 ba=
ckend.
What can I do to get the server to abort at this point? Use PANIC instead o=
f ERROR in the elog call perhaps?