On Fri, Mar 04, 2011 at 05:52:29PM +0200, Heikki Linnakangas wrote:
> Hmm, if these all came from the same database, then it looks OldestXmin
> has moved backwards. That would explain the warnings. First one vacuum
> determines that all the tuples are visible to everyone and sets the
> flag. Then another vacuum runs with an older OldestXmin, and determines
> that there's a tuple on the page with an xmin that is not yet visible to
> everyone, hence it thinks that the flag should not have been set yet.
>
> Looking at the code, I don't see how that situation could arise, though.
> The value calculated by GetOldestXmin() should never move backwards. And
> GetOldestXmin() is called in lazy_vacuum_rel(), after it has acquired a
> lock on the table, which should protect from a race condition where two
> vacuums could run on the table one after another, in a way where the
> later vacuum runs with an OldestXmin calculated before the first vacuum.
>
> Hmm, fiddling with vacuum_defer_cleanup_age on the fly could cause that,
> though. You don't do that, do you?
No.
I've updated the patch to collect db and schema and added Merlins patch as
well and run it for a while. The attached log is all the debug messages
for pg_statistic page 333 from one database. I've also attached the two
most recent page images for that particular page, the last digits in the
filename are the hour and minute of when the page was saved.
What else can I be doing to help figure this out?
Thanks
-dg
--
David Gould daveg@sonic.net 510 536 1443 510 282 0869
If simplicity worked, the world would be overrun with insects.
