Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > BTW, I forgot to mention that I intend to apply this patch later today,
> > regardless of whatever solution we may decide for the problem below; we
> > can add it later, and it certainly is a corner case.
> 
> Please don't.  If you don't have a solution for that, then it doesn't
> work.

Ok.  Let's see what possible solutions we have.

1. automatically vacuum the newly created database after creation,
before returning from createdb() to the user.  This doesn't work because
we are not connected to it.

2. "Fix" pg_class in the new database after creation.  Same problem as
above.

2. force the user to issue a database-wide vacuum as first thing in the
newly created database.  Not sure how to implement the restriction
(needs an additional pg_database column?).  Doesn't seem very user
friendly.

3. automatically change the first single-table VACUUM in a database into
a database-wide vacuum.  Additionally to the problems from the precedent
proposal, this one breaks principle of least surprise.

4. mandate that not connectable databases must be vacuumed regularly,
just like any other.  This follows the KISS principle.


The last one is the only one that seems relatively reasonable to me ...
Plus it doesn't seem too onerous, since a template database is probably
very small and vacuuming should be cheap.  There is one problem: if a
database is not connectable, how would the user vacuum it?  Autovacuum
would do it, but not everybody uses it.  We could hack vacuumdb so that
it connects elsewhere, changes the datallowconn bit, vacuum the db, and
change the datallowconn bit back.

I'm outta ideas for now ... any other?

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Reply via email to