Horton

Re: [HACKERS] Re: PD_ALL_VISIBLE flag was incorrectly set happend during repeatable vacuum

Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>

View thread
From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
To: daveg <daveg@sonic.net>
Cc: Maxim Boguk <maxim.boguk@gmail.com>, Fujii Masao <masao.fujii@gmail.com>, pgsql-admin@postgresql.org, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2011-02-28T22:00:54Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix a violation of WAL coding rules in the recent patch to include an

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