Re: [HACKERS] Non-transactional pg_class, try 2

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: [HACKERS] Non-transactional pg_class, try 2
Дата
Msg-id 20060628234408.GA460@surnet.cl
обсуждение исходный текст
Ответ на Non-transactional pg_class, try 2  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: "Magnus Hagander"
Дата:
Сообщение: Re: Client build of MSVC6+ patch
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: [HACKERS] Non-transactional pg_class, try 2