Re: [HACKERS] Re: PD_ALL_VISIBLE flag was incorrectly set happend during repeatable vacuum
От | Robert Haas |
---|---|
Тема | Re: [HACKERS] Re: PD_ALL_VISIBLE flag was incorrectly set happend during repeatable vacuum |
Дата | |
Msg-id | AANLkTi=Ye7AoF7_uVQfPVn-ok2VOp65mi0xU3H7kCke3@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Re: PD_ALL_VISIBLE flag was incorrectly set happend during repeatable vacuum (Greg Stark <gsstark@mit.edu>) |
Ответы |
Re: [HACKERS] Re: PD_ALL_VISIBLE flag was incorrectly set happend during repeatable vacuum
|
Список | pgsql-admin |
On Mon, Feb 28, 2011 at 10:32 PM, Greg Stark <gsstark@mit.edu> wrote: > On Tue, Mar 1, 2011 at 1:43 AM, David Christensen <david@endpoint.com> wrote: >> Was this cluster upgraded to 8.4.4 from 8.4.0? It sounds to me like a known bug in 8.4.0 which was fixed by this commit: >> > > The reproduction script described was running vacuum repeatedly. A > single vacuum run out to be sufficient to clean up the problem if it > was left-over. > > I wonder if it would help to write a regression test that runs 100 or > so vacuums and see if the bulid farm turns up any examples of this > behaviour. One other thing to keep in mind here is that the warning message we've chosen can be a bit misleading. The warning is: WARNING: PD_ALL_VISIBLE flag was incorrectly set in relation "test" page 1 ...which implies that the state of the tuples is correct, and that the page-level bit is wrong in comparison. But I recently saw a case where the infomask got clobbered, resulting in this warning. The page level bit was correct, at least relative to the intended page contents; it was the a tuple on the page that was screwed up. It might have been better to pick a more neutral phrasing, like "page is marked all-visible but some tuples are not visible". -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-admin по дате отправления: