Re: Database OID xxxxx now seems to belong to "foo"

The renames go very fast. It's one of the main reasons I like it. I
run them manually, so I can say for certain that they have not failed
"mid stream" where "midstream" seems to take under a second.

-----Original Message-----
From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
Sent: Tuesday, March 11, 2008 12:51 PM
To: Alvaro Herrera
Cc: Gauthier, Dave; pgsql-general(at)postgresql(dot)org
Subject: Re: [GENERAL] Database OID xxxxx now seems to belong to "foo"

Alvaro Herrera <alvherre(at)commandprompt(dot)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