On 08.03.2011 10:49, daveg wrote:
On Tue, Mar 08, 2011 at 10:37:24AM +0200, Heikki Linnakangas wrote:
On 08.03.2011 10:00, Heikki Linnakangas wrote:
Another idea is to give up on the warning when it appears that
oldestxmin has moved backwards, and assume that it's actually fine. We
could still warn in other cases where the flag appears to be incorrectly
set, like if there is a deleted tuple on the page.
This is probably a better idea at least in back-branches. It also
handles the case of twiddling vacuum_defer_cleanup_age, which tracking
two xmins per transactions would not handle.
Here's a patch. I also changed the warning per Robert's suggestion.
Anyone see a hole in this?
It would be helpful to have the dbname and schema in the message in addition
to the relname. I added those to the original diagnostic patch as it was not
clear that the messages were all related to the same page/table/dg.
Hmm, we don't usually include database name and schema in messages like
this. There's a couple of other warnings in vacuum, too, that only print
the table name. I have to admit that the database name was crucial in
tracking this down, but in hindsight you could've added database name to
log_line_prefix for the same effect. If you have several databases with
same schema, that's a good idea anyway. So in the end, I decided not to
include it.
Also, in your comment you might mention that multiple databases are one way
we could see oldestxmin move backwards.
Ok, I added a comment to GetOldestXmin() explaining that.
Committed. Thanks David for your help in debugging this! And thanks to
everyone else for helping out too.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
