Re: buffer assertion tripping under repeat pgbench load

From: Greg Stark <stark(at)mit(dot)edu>
To: Greg Smith <greg(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: buffer assertion tripping under repeat pgbench load
Date: 2012-12-31 00:16:24
Message-ID: CAM-w4HM8v_EQsWDghj9=grLfFpgxScgKKuggwOskem2q-wg0sA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Dec 30, 2012 at 3:07 AM, Greg Smith <greg(at)2ndquadrant(dot)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

In response to

Browse pgsql-hackers by date

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