Re: PD_ALL_VISIBLE flag warning - Mailing list pgsql-admin
| From | Jonathan Foy |
|---|---|
| Subject | Re: PD_ALL_VISIBLE flag warning |
| Date | |
| Msg-id | g2v4b46b5f01004080557j25cb26f1ic054f92b4f543baa@mail.gmail.com Whole thread Raw |
| In response to | Re: PD_ALL_VISIBLE flag warning (Greg Stark <gsstark@mit.edu>) |
| Responses |
Re: PD_ALL_VISIBLE flag warning
|
| List | pgsql-admin |
Thanks for the reply...
We have an unhealthy habit of not updating very often around here, one that I'm trying to fix. We run both 8.1 and 8.4, and we're testing the update to 8.1.20 this weekend....from 8.1.3. Across the board 8.4 update will take much more testing due to the typing issue. Other 8.4 updates will take place soon.
Anyway, my guilt about outdated versions aside...
We never actually ran 8.4.0. We went straight from 8.3.3 to 8.4.1. I did a full dump/restore from the 8.3.3 database into the 8.4.1 database (using the 8.4 pg_dump), partitioning as I went. The table in question was not partitioned in 8.3, the 8.4 dump/restore seemed as good a place to do the partitioning as any. I don't specifically remember doing it, but I almost always do a manual vacuum/analyze after a restore. Autovacuum is/was also turned on. According to the stats, everything seems to have been at least vacuumed on 2/15 (the date of the update I believe), so it is doubtful to me that any of the tables, especially the currently active partition, would have gone un-vacuumed as of 4/1.
The logs for that day have already rotated into less-easily available storage, but I'm considering retrieving them to look for any aborts/rollbacks.
Also, for what it's worth, we never delete rows from this table, we only insert and update.
I have not seen the warning since.
Sound like trouble?
We have an unhealthy habit of not updating very often around here, one that I'm trying to fix. We run both 8.1 and 8.4, and we're testing the update to 8.1.20 this weekend....from 8.1.3. Across the board 8.4 update will take much more testing due to the typing issue. Other 8.4 updates will take place soon.
Anyway, my guilt about outdated versions aside...
We never actually ran 8.4.0. We went straight from 8.3.3 to 8.4.1. I did a full dump/restore from the 8.3.3 database into the 8.4.1 database (using the 8.4 pg_dump), partitioning as I went. The table in question was not partitioned in 8.3, the 8.4 dump/restore seemed as good a place to do the partitioning as any. I don't specifically remember doing it, but I almost always do a manual vacuum/analyze after a restore. Autovacuum is/was also turned on. According to the stats, everything seems to have been at least vacuumed on 2/15 (the date of the update I believe), so it is doubtful to me that any of the tables, especially the currently active partition, would have gone un-vacuumed as of 4/1.
The logs for that day have already rotated into less-easily available storage, but I'm considering retrieving them to look for any aborts/rollbacks.
Also, for what it's worth, we never delete rows from this table, we only insert and update.
I have not seen the warning since.
Sound like trouble?
On Thu, Apr 8, 2010 at 12:59 AM, Greg Stark <gsstark@mit.edu> wrote:
On Thu, Apr 1, 2010 at 2:10 PM, Jonathan Foy <thefoy@gmail.com> wrote:This is a warning about a fairly serious data corruption problem. In
> 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.
the worst case prior queries returned incorrect results -- which if
those results were used to calculate subsequent updates could have
caused your data to be inconsistent.
Specifically, having that flag set would cause rows to be returned
which should not have been returned, either because they had been
deleted, the transaction inserting them aborted, or they had been
updated (causing duplicate copies of the same row to be returned).
There was a bug which could cause this in 8.4.0 but it was fixed in
8.4.1. You say you're running 8.4.1 (you should be running 8.4.3
though none of the subsequent bug-fixes are as serious if the SSL
security vulnerability isn't relevant) so this is quite worrisome.
Nobody else has reported anything similar though.
Is it possible these pages have never been vacuumed since you updated
from 8.4.0 to 8.4.1? I'm not sure how likely that is. In 8.4 Postgres
tries to avoid vacuuming pages that don't need it so it's possible
this situation could live on for longer than in the past.
I think a regular "VACUUM" of every table should guarantee that any
remnants of this bug from 8.4.0 are cleaned up. If you do this and
possibly get some more warnings from it but never see it again
afterwards then I would assume they're leftovers from that old bug.
--
greg
pgsql-admin by date: