Re: Re: PD_ALL_VISIBLE flag was incorrectly set happend during repeatable vacuum
| От | daveg |
|---|---|
| Тема | Re: Re: PD_ALL_VISIBLE flag was incorrectly set happend during repeatable vacuum |
| Дата | |
| Msg-id | 20110308084956.GE21941@sonic.net обсуждение исходный текст |
| Ответ на | Re: Re: PD_ALL_VISIBLE flag was incorrectly set happend during repeatable vacuum (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
| Ответы |
Re: Re: PD_ALL_VISIBLE flag was incorrectly set happend
during repeatable vacuum
|
| Список | pgsql-hackers |
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. Also, in your comment you might mention that multiple databases are one way we could see oldestxmin move backwards. -dg -- David Gould daveg@sonic.net 510 536 1443 510 282 0869 If simplicity worked, the world would be overrun with insects.
В списке pgsql-hackers по дате отправления: