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 по дате отправления: