On Tue, Mar 01, 2011 at 12:00:54AM +0200, Heikki Linnakangas wrote: > 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. I ran vacuums on all the affected tables last night. I plan to take a downtime to clear the buffer cache and then to run vacuums on all the dbs in the cluster. Most but not all the tables involved are catalogs. However, I could probably pick up your old patch sometime next week if it recurrs and send you page images. -dg -- David Gould daveg@xxxxxxxxx 510 536 1443 510 282 0869 If simplicity worked, the world would be overrun with insects. -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
