Re: [HACKERS] Re: PD_ALL_VISIBLE flag was incorrectly set happend during repeatable vacuum
daveg <daveg@sonic.net>
From: daveg <daveg@sonic.net>
To: David Christensen <david@endpoint.com>
Cc: 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-01T21:17:45Z
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 →
-
Fix a violation of WAL coding rules in the recent patch to include an
- 7fc7a7c4d082 9.0.0 cited
On Mon, Feb 28, 2011 at 07:43:39PM -0600, David Christensen wrote: > > On Feb 28, 2011, at 3:28 PM, daveg wrote: > > > Anything new on this? I'm seeing at on one of my clients production boxes. > > Also, what is the significance, ie what is the risk or damage potential if > > this flag is set incorrectly? > > > 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: > > commit 7fc7a7c4d082bfbd579f49e92b046dd51f1faf5f > Author: Tom Lane <tgl@sss.pgh.pa.us> > Date: Mon Aug 24 02:18:32 2009 +0000 > > Fix a violation of WAL coding rules in the recent patch to include an > "all tuples visible" flag in heap page headers. The flag update *must* > be applied before calling XLogInsert, but heap_update and the tuple > moving routines in VACUUM FULL were ignoring this rule. A crash and > replay could therefore leave the flag incorrectly set, causing rows > to appear visible in seqscans when they should not be. This might explain > recent reports of data corruption from Jeff Ross and others. > > In passing, do a bit of editorialization on comments in visibilitymap.c. > > oy:postgresql machack$ git describe --tag 7fc7a7c4d082bfbd579f49e92b046dd51f1faf5f > REL8_4_0-190-g7fc7a7c > > If the flag got twiddled while running as 8.4.0, the incorrect PD_ALL_VISIBLE flag would (obviously) not be fixed by the upgrade to 8.4.4. (Is this a separate issue?) This cluster was installed with 8.4.4. So it is still an existing problem. Also, to my recollection, this cluster has never crashed. -dg -- David Gould daveg@sonic.net 510 536 1443 510 282 0869 If simplicity worked, the world would be overrun with insects.