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@xxxxxxxxxxxxx] Sent: Tuesday, March 11, 2008 12:51 PM To: Alvaro Herrera Cc: Gauthier, Dave; pgsql-general@xxxxxxxxxxxxxx Subject: Re: Database OID xxxxx now seems to belong to "foo" Alvaro Herrera <alvherre@xxxxxxxxxxxxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
