Re: buffer assertion tripping under repeat pgbench load - Mailing list pgsql-hackers

From Greg Stark
Subject Re: buffer assertion tripping under repeat pgbench load
Date
Msg-id CAM-w4HM8v_EQsWDghj9=grLfFpgxScgKKuggwOskem2q-wg0sA@mail.gmail.com
Whole thread Raw
In response to Re: buffer assertion tripping under repeat pgbench load  (Greg Smith <greg@2ndQuadrant.com>)
List pgsql-hackers
On Sun, Dec 30, 2012 at 3:07 AM, Greg Smith <greg@2ndquadrant.com> wrote:
> It is a strange power of two to be appearing there.  I can follow your
> reasoning for why this could be a bit flipping error.  There's no sign of
> that elsewhere though, no other crashes under load.  I'm using this server
> here because it's worked fine for a while now.

Hm. Another idea. Can you use taskset to bind postgres to just one
processor at a time and see if it's reproducible on both processors?
The processor affinity is inherited across fork so doing it once on
the postmaster before starting pgbench ought to be sufficient.

If it's not a hardware error then the most plausible explanation seems
to me that one of the one of the bitsets such as t_infomask or
something is being set based on a wild pointer. For example
src/backend/commands/trigger.c:3469 and 3572 set this bit offset on a
bitmask at the end of a pointer. These lines haven't changed in 4
years but you don't have any command triggers on this database do you?
Maybe this pointer isn't being initialized?

-- 
greg



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: proposal: a width specification for s specifier (format function), fix behave when positional and ordered placeholders are used
Next
From: Tom Lane
Date:
Subject: Re: Making view dump/restore safe at the column-alias level