Re: buffer assertion tripping under repeat pgbench load

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: buffer assertion tripping under repeat pgbench load
Дата
Msg-id CAM-w4HM8v_EQsWDghj9=grLfFpgxScgKKuggwOskem2q-wg0sA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: buffer assertion tripping under repeat pgbench load  (Greg Smith <greg@2ndQuadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: proposal: a width specification for s specifier (format function), fix behave when positional and ordered placeholders are used
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Making view dump/restore safe at the column-alias level