Re: [HACKERS] Non-transactional pg_class, try 2 - Mailing list pgsql-patches

From Alvaro Herrera
Subject Re: [HACKERS] Non-transactional pg_class, try 2
Date
Msg-id 20060628234408.GA460@surnet.cl
Whole thread Raw
In response to Non-transactional pg_class, try 2  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: [HACKERS] Non-transactional pg_class, try 2  (Alvaro Herrera <alvherre@commandprompt.com>)
Re: [HACKERS] Non-transactional pg_class, try 2  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-patches
Alvaro Herrera wrote:
> Tom Lane wrote:
> > Alvaro Herrera <alvherre@commandprompt.com> 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.

pgsql-patches by date:

Previous
From: "Magnus Hagander"
Date:
Subject: Re: Client build of MSVC6+ patch
Next
From: Alvaro Herrera
Date:
Subject: Re: [HACKERS] Non-transactional pg_class, try 2