Alvaro Herrera <alvherre@commandprompt.com> writes:
> 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.
I agree, all of those are a bit ugly.
> 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.
This isn't as bad as all that. Suppose we make a database-wide VACUUM
FREEZE set relminxid = FrozenXid (or maybe InvalidXid would be better)
for all the tables, and also put this into datminxid. This value can
*not* be combined with other relminxid values, and therefore the rule is
that all other forms of VACUUM forcibly process every rel with this
relminxid, setting relminxid to current XID counter; and then they can
validly compute a minimum database-wide value of relminxid to put into
datminxid.
> 4. mandate that not connectable databases must be vacuumed regularly,
> just like any other. This follows the KISS principle.
If we went down that path, I think we'd essentially abandon the notion
of VACUUM FREEZE altogether. Which would certainly simplify the system,
but I'm not sure it's a step forward.
The big objection to either of these approaches is that they give up the
possibility of suppressing vacuums permanently on large read-only
tables, which is one of the goals that we had in mind for VACUUM FREEZE.
The data warehousing guys will be on our case if we put that idea
permanently off the table.
I remember we had decided against the idea of having the first
modification of a frozen table change its relminxid, but I've forgotten
what the rationale was ... do you remember? It's starting to look like
not such a bad idea after all. If we added a hack to do that then the
relminxid bookkeeping rules would get a lot simpler.
regards, tom lane
