On 15.03.2011 02:01, Lane Stevens wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5928
> Logged by: Lane Stevens
> Email address: lane@mobilsense.com
> PostgreSQL version: 8.4.4
> Operating system: CentOS
> Description: PD_ALL_VISIBLE flag incorrectly set warning messages
> Details:
>
> A series of messages similar to the following were logged:
>
> pgsql.log:Mar 14 16:38:44 bo01 preprod[5462]: [2-1] eval25WARNING:
> PD_ALL_VISIBLE flag was incorrectly set in relation "pg_statistic" page 45
>
> This happened at least one other time on Jan 10 with the same version of the
> database. So far I have been unable to replicate the error.
>
> Kernel is: 2.6.18-164.15.1.el5
> postgresql is: postgresql-8.4.4-2PGDG.el5
This is a known issue, fixed recently in the git repository. See:
http://archives.postgresql.org/message-id/4D75E201.20402@enterprisedb.com
and the fix:
commit b42225c101e61afdc9b4f5873654bc1e0c9f9179
Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
Date: Tue Mar 8 20:13:52 2011 +0200
Don't throw a warning if vacuum sees PD_ALL_VISIBLE flag set on a
page that
contains newly-inserted tuples that according to our OldestXmin are not
yet visible to everyone. The value returned by GetOldestXmin() is
conservative,
and it can move backwards on repeated calls, so if we see that
contradiction
between the PD_ALL_VISIBLE flag and status of tuples on the page,
we have to
assume it's because an earlier vacuum calculated a higher
OldestXmin value,
and all the tuples really are visible to everyone.
We have received several reports of this bug, with the
"PD_ALL_VISIBLE flag
was incorrectly set in relation ..." warning appearing in logs. We were
finally able to hunt it down with David Gould's help to run extra
diagnostics
in an environment where this happened frequently.
Also reword the warning, per Robert Haas' suggestion, to not imply
that the
PD_ALL_VISIBLE flag is necessarily at fault, as it might also be a
symptom
of corruption on a tuple header.
Backpatch to 8.4, where the PD_ALL_VISIBLE flag was introduced.
This fix will be included in the next version (8.4.8). Assuming you're
seeing the same issue, the warning is harmless and can be ignored.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com