PD_ALL_VISIBLE flag warning

From: Jonathan Foy <thefoy(at)gmail(dot)com>
To: pgsql-admin(at)postgresql(dot)org
Subject: PD_ALL_VISIBLE flag warning
Date: 2010-04-01 13:10:39
Message-ID: g2o4b46b5f01004010610ib8625426uae6ee90ac1435ba1@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

Hello

I came in this morning and noticed this warning sitting in my inbox quite a
few times...

WARNING: PD_ALL_VISIBLE flag was incorrectly set in relation "table_2010q1"
page 471118
WARNING: PD_ALL_VISIBLE flag was incorrectly set in relation "table_2010q1"
page 471119
WARNING: PD_ALL_VISIBLE flag was incorrectly set in relation "table_2010q1"
page 471120
....

and I'm wondering how worked up I should be getting.

I'm trying to do due diligence on my side and am digging through archives,
but just in case it's a cause for greater alarm than I think it is I'm going
to throw this out there and see what those more experienced that I say.

Postgres version 8.4.1, redhat 5.3.

The table in question is about 6 million rows, a single partition in a
larger set. A relatively heavy load (mass insert followed by a mass update)
takes place each morning, during the time period where I was seeing this
error. Auto-vacuum apparently kicked off at this time as well (auto-analyze
is showing last-run at 4:27 AM, auto-vacuum at 8:48). The first warning
kicked off at 4:55.

My assumption here is that the load from the inserts/updates was interfering
with auto-vacuum in some way, and resulted in the above warnings. Is this a
reasonable assumption at all? I'm under the impression that auto-vacuum
will kill itself if it notices that it's hurting performance, but I wouldn't
think it should throw all of these warnings...does it indicate poor
auto-vacuum configuration? I admit that said configuration is an area that
I've been meaning to look into more (upgraded from 8.1 where we didn't use
auto-vacuum), but hasn't ended up on the top of the priorities list yet.

Let me know if I'm not providing enough info.

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Francisco Reyes 2010-04-01 15:06:43 Re: pg_restore : change schema
Previous Message Christophe Dore 2010-04-01 09:29:26 pg_restore : change schema