Re: Database OID xxxxx now seems to belong to "foo" - Mailing list pgsql-general

From Tom Lane
Subject Re: Database OID xxxxx now seems to belong to "foo"
Date
Msg-id 24392.1205254278@sss.pgh.pa.us
Whole thread Raw
In response to Re: Database OID xxxxx now seems to belong to "foo"  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-general
Alvaro Herrera <alvherre@commandprompt.com> writes:
> Gauthier, Dave wrote:
>> I'm running 8.2.0 on Linux.

> It's not turned on by default (and it's not on 8.2), so it's probably
> not vacuuming anything.  On 8.2 there are enough protections that this
> shouldn't be the actual problem though -- as soon as you get anywhere
> near a failure, the system shuts itself down (but autovac gets a chance
> to fix the problem for you before that happens, even if it's turned
> off).

Yeah, if it's 8.2.anything then XID wraparound should be an impossible
situation to get into; so we need a new theory.

Right offhand, the only way I can see for there to be a problem with
the flat pg_database file being out of sync with the real catalog
is if a CREATE/DROP/RENAME DATABASE aborts during transaction commit,
after having already updated the flat file.  This is certainly
conceivable but it would take some rather hairy error.  Dave, did
you have any recent database-manipulating commands go wacko on you?

(Alvaro's point about it possibly being an already-fixed bug is
definitely valid.  I'm too lazy to go trawl the CVS history for
bugs near transaction commit, though.)

            regards, tom lane

pgsql-general by date:

Previous
From: Richard Huxton
Date:
Subject: Re: Database OID xxxxx now seems to belong to "foo"
Next
From: Tomás Di Doménico
Date:
Subject: Re: PostgreSQL and MOLAP ?