Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugspgsql-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);

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:


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


pgsql-hackers by date

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

pgsql-bugs by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group