Horton

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

Robert Haas <robertmhaas@gmail.com>

View thread
From: Robert Haas <robertmhaas@gmail.com>
To: Greg Stark <gsstark@mit.edu>
Cc: David Christensen <david@endpoint.com>, daveg <daveg@sonic.net>, Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>, Maxim Boguk <maxim.boguk@gmail.com>, Fujii Masao <masao.fujii@gmail.com>, pgsql-admin@postgresql.org, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2011-03-01T13:40:37Z
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 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".

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company