Re: pg_group_name_index corrupt?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pg_group_name_index corrupt?
Дата
Msg-id 840.957480414@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pg_group_name_index corrupt?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
> The Hermit Hacker <scrappy@hub.org> writes:
>> Hadn't thought of that ... but ... and you aren't going to like this
>> ... if I delete/vacuum/insert/vacuum ... INDEX TUPLES increases by 1, HEAP
>> increases by one ... I'm up to 3->4 now, and would go 4->5 if I were to do
>> it again ...

> That definitely sounds like VACUUM thinks there's an old open transaction
> somewhere and so it doesn't want to clean out the dead tuples.

After looking some more at this, I'm not convinced that the problem
Hiroshi found explains everything Marc is seeing.  Having multiple
copies of the pg_group indexes would certainly explain missing index
tuples in any one copy.  But what about the behavior above?  It still
seems that VACUUM is not cleaning out dead tuples from the table itself.

Marc, is it possible that you have any backends that are in the middle
of a transaction and have just been sitting that way for hours or days?
If so, that'd explain VACUUM's refusal to remove tuples.  Another
symptom you should look for is notices likeNOTICE:  RegisterSharedInvalid: SI buffer overflowNOTICE:
InvalidateSharedInvalid:cache state reset
 
in the postmaster log --- there'll probably be quite a few if there's
a hung backend somewhere.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Mitch Vincent"
Дата:
Сообщение: Re: Why Not MySQL?
Следующее
От: The Hermit Hacker
Дата:
Сообщение: Re: pg_group_name_index corrupt?