Re: Re: PD_ALL_VISIBLE flag was incorrectly set happend during repeatable vacuum
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
To: daveg <daveg@sonic.net>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>, Greg Stark <gsstark@mit.edu>, Maxim Boguk <maxim.boguk@gmail.com>, bricklen@gmail.com
Date: 2011-03-08T19:00:14Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix a violation of WAL coding rules in the recent patch to include an
- 7fc7a7c4d082 9.0.0 cited
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