Re: pg_group_name_index corrupt? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_group_name_index corrupt?
Date
Msg-id 840.957480414@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_group_name_index corrupt?  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: "Mitch Vincent"
Date:
Subject: Re: Why Not MySQL?
Next
From: The Hermit Hacker
Date:
Subject: Re: pg_group_name_index corrupt?