Re: Database OID xxxxx now seems to belong to "foo"
От | Tom Lane |
---|---|
Тема | Re: Database OID xxxxx now seems to belong to "foo" |
Дата | |
Msg-id | 24392.1205254278@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Database OID xxxxx now seems to belong to "foo" (Alvaro Herrera <alvherre@commandprompt.com>) |
Список | 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 по дате отправления: