Re: Re: [ADMIN] PD_ALL_VISIBLE flag was incorrectly set happend during repeatable vacuum - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Re: [ADMIN] PD_ALL_VISIBLE flag was incorrectly set happend during repeatable vacuum
Date
Msg-id 4D6C1B16.6030708@enterprisedb.com
Whole thread Raw
In response to Re: [ADMIN] PD_ALL_VISIBLE flag was incorrectly set happend during repeatable vacuum  (Fujii Masao <masao.fujii@gmail.com>)
Responses Re: Re: [ADMIN] PD_ALL_VISIBLE flag was incorrectly set happend during repeatable vacuum  (Maxim Boguk <maxim.boguk@gmail.com>)
Re: Re: [ADMIN] PD_ALL_VISIBLE flag was incorrectly set happend during repeatable vacuum  (daveg <daveg@sonic.net>)
List pgsql-hackers
On 28.02.2011 23:28, daveg wrote:
> On Wed, Jan 12, 2011 at 10:46:14AM +0200, Heikki Linnakangas wrote:
>> We'll likely need to go back and forth a few times with various
>> debugging patches until we get to the heart of this..
>
> Anything new on this? I'm seeing at on one of my clients production boxes.

I haven't heard anything from the OP since.

> Also, what is the significance, ie what is the risk or damage potential if
> this flag is set incorrectly?

Sequential scans will honor the flag, so you might see some dead rows
incorrectly returned by a sequential scan. That's the only "damage", but
an incorrectly set flag could be a sign of something more sinister, like
corrupt tuple headers. The flag should never be set incorrectly, so if
you see that message you have hit a bug in PostgreSQL, or you have bad
hardware.

This flag is quite new, so a bug in PostgreSQL is quite possible. If you
still have a backup that contains those incorrectly set flags, I'd like
to see what the page looks like.

--
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: SR standby hangs
Next
From: Josh Berkus
Date:
Subject: Re: Re: Why our counters need to be time-based WAS: WIP: cross column correlation ...