Re: erroneous restore into pg_catalog schema
От | Tom Lane |
---|---|
Тема | Re: erroneous restore into pg_catalog schema |
Дата | |
Msg-id | 9393.1368472577@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: erroneous restore into pg_catalog schema (Andres Freund <andres@2ndquadrant.com>) |
Список | pgsql-hackers |
Andres Freund <andres@2ndquadrant.com> writes: > On 2013-05-13 14:48:52 -0400, Tom Lane wrote: >> Andres Freund <andres@2ndquadrant.com> writes: >>> DROPing and recreating a new index in --single mode isn't that >>> uncommon... >> Surely you'd just REINDEX it instead. Moreover, if it isn't a system >> index already, why are you doing this in --single mode at all? > The last case I had was that an index was corrupted in a way that > autovacuum got stuck on the corrupt index and wasn't killable. Without > single mode it was hard to be fast enough to drop the index before > autovac grabbed the lock again. Meh. Actually, after looking closer at xlog.c, the OID counter starts out at FirstBootstrapObjectId, which is not what I'd been thinking. So a value less than that must indicate wraparound, which presumably never happens during initdb. We could just change the code to if (ShmemVariableCache->nextOid < ((Oid) FirstBootstrapObjectId)) { /* wraparound whilein standalone environment */ ShmemVariableCache->nextOid = FirstNormalObjectId; ShmemVariableCache->oidCount= 0; } which is a bit asymmetric-looking but should do the right thing in all cases. regards, tom lane
В списке pgsql-hackers по дате отправления: