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
