Alvaro Herrera wrote: > Tom Lane wrote: > > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > > What I'm after is not freezing for read-only media, nor archive, nor > > > read-only tables. What I'm after is removing the requirement that all > > > databases must be vacuumed wholly every 2 billion transactions. > > > > Well, if that's the only goal then I hardly think we need to have a > > discussion, because your alternative #1 is *obviously* the winner: > > > > > 1. Remove the special case, i.e., process frozen databases in VACUUM > > > like every other database. > > > This is the easiest, because no extra logic is needed. Just make > > > sure they are vacuumed in time. The only problem would be that we'd > > > need to uselessly vacuum tables that we know are frozen, from time to > > > time. But then, those tables are probably small, so what's the > > > problem with that? > > I'm happy to do at least this for 8.2. We can still try to do the > non-transactional catalog later, either in this release or the next; the > code is almost there, and it'll be easier to discuss/design because > we'll have taken the relminxid stuff out of the way.
I attach a patch pursuant to this idea (lacking doc patches for the maintenance section.) This patch has the nasty side effect mentioned above -- people will have to set template0 as connectable and manually run vacuum on it periodically, unless they run autovacuum. A future improvement in this area would be to allow frozen tables and frozen databases, removing this requirement. But I'm inclined to apply it as is, in the spirit of incremental improvement. Objectors please speak up! -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
