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.

So if everyone agrees, I'll do this now.  Beware -- this may make you
vacuum databases that you previously weren't vacuuming.  (I really doubt
anyone is setting datallowconn=false just to skip vacuuming big
databases, but there are people with strange ideas out there.)

> So if you want to bring in the other goals that you're trying to pretend
> aren't there, step right up and do it.  You have not here made a case
> that would convince anyone that we shouldn't just do #1 and be done with
> it.

We can do it in a separate discussion.

Alvaro Herrera                      
The PostgreSQL Company - Command Prompt, Inc.

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
       subscribe-nomail command to [EMAIL PROTECTED] so that your
       message can get through to the mailing list cleanly

Reply via email to