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
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 |