From: daveg <daveg@sonic.net>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Greg Stark <gsstark@mit.edu>
Cc: David Christensen <david@endpoint.com>
Cc: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
Cc: Maxim Boguk <maxim.boguk@gmail.com>
Cc: Fujii Masao <masao.fujii@gmail.com>
Cc: pgsql-admin@postgresql.org, PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Re: PD_ALL_VISIBLE flag was incorrectly set happend during repeatable vacuum
Date: Wed, 2 Mar 2011 23:12:08 -0800
Message-ID: <20110303071208.GA4053@sonic.net> (raw)
In-Reply-To: <AANLkTi=Ye7AoF7_uVQfPVn-ok2VOp65mi0xU3H7kCke3@mail.gmail.com>
References: <AANLkTino+Gc2vvOVdzCPRRXW-N7R5=ikYMnNKT5W=mk1@mail.gmail.com>
<AANLkTikw==USr3+4Mt+w97P3ymux-Bhn0G7Ad0ZJHbqG@mail.gmail.com>
<4D2D6A56.9060808@enterprisedb.com>
<20110228212832.GH26397@sonic.net>
<1B3CCBDD-4AC6-404A-9E26-DB4CA2554228@endpoint.com>
<AANLkTi=xq4SV6jwA7txvrbEWocyeiU6XiTG=-zVy+7Dq@mail.gmail.com>
<AANLkTi=Ye7AoF7_uVQfPVn-ok2VOp65mi0xU3H7kCke3@mail.gmail.com>
On Tue, Mar 01, 2011 at 08:40:37AM -0500, Robert Haas wrote:
> On Mon, Feb 28, 2011 at 10:32 PM, Greg Stark <gsstark@mit.edu> wrote:
> > On Tue, Mar 1, 2011 at 1:43 AM, David Christensen <david@endpoint.com> wrote:
> >> Was this cluster upgraded to 8.4.4 from 8.4.0? It sounds to me like a known bug in 8.4.0 which was fixed by this commit:
> >>
> >
> > The reproduction script described was running vacuum repeatedly. A
> > single vacuum run out to be sufficient to clean up the problem if it
> > was left-over.
> >
> > I wonder if it would help to write a regression test that runs 100 or
> > so vacuums and see if the bulid farm turns up any examples of this
> > behaviour.
>
> One other thing to keep in mind here is that the warning message we've
> chosen can be a bit misleading. The warning is:
>
> WARNING: PD_ALL_VISIBLE flag was incorrectly set in relation "test" page 1
>
> ...which implies that the state of the tuples is correct, and that the
> page-level bit is wrong in comparison. But I recently saw a case
> where the infomask got clobbered, resulting in this warning. The page
> level bit was correct, at least relative to the intended page
> contents; it was the a tuple on the page that was screwed up. It
> might have been better to pick a more neutral phrasing, like "page is
> marked all-visible but some tuples are not visible".
Yeesh. Yikes. I hope that this is not the case as we are seeing thousands of
these daily on each of 4 large production hosts. Mostly on catalogs,
especially pg_statistic. However it does occur on some high delete/insert
traffic user tables too.
Question: what would be the consequence of simply patching out the setting
of this flag? Assuming that the incorrect PD_ALL_VISIBLE flag is the only
problem (big assumption perhaps) then simply never setting it would at least
avoid the possibility of returning wrong answers, presumably at some
performance cost. We possibly could live with that until we get a handle
on the real cause and fix.
I had a look and don't really see anything except vacuum_lazy that sets it,
so it seems simple to disable.
Or have I understood this incorrectly?
Anything else I can be doing to try to track this down?
-dg
--
David Gould daveg@sonic.net 510 536 1443 510 282 0869
If simplicity worked, the world would be overrun with insects.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-admin@postgresql.org
Cc: daveg@sonic.net, robertmhaas@gmail.com, gsstark@mit.edu, david@endpoint.com, heikki.linnakangas@enterprisedb.com, maxim.boguk@gmail.com, masao.fujii@gmail.com, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Re: PD_ALL_VISIBLE flag was incorrectly set happend during repeatable vacuum
In-Reply-To: <20110303071208.GA4053@sonic.net>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox