On 2013-05-13 14:48:52 -0400, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > On 2013-05-13 14:35:47 -0400, Tom Lane wrote:
> >> That is, in fact, exactly what we want to do and must do during initdb.
> >> If you change anything about this code you'll break the way the
> >> post-bootstrap initdb steps assign OIDs.
>
> > Well, then we should use some other way to discern from those both
> > cases. If you currently execute CREATE TABLE or something else in
> > --single user mode the database cannot safely be pg_upgraded anymore
> > since the oids might already be used in a freshly initdb'ed cluster in
> > the new version.
>
> [ shrug... ] In the list of ways you can break your system in --single
> mode, that one has got to be exceedingly far down the list.
Well, sure there are loads of ways where you can intentionally break
things. But I'd say that it's not exactly obvious that CREATE INDEX
can break things.
> > 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.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services