Re: [PATCHES] Non-transactional pg_class, try 2 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCHES] Non-transactional pg_class, try 2
Date
Msg-id 23140.1151357193@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCHES] Non-transactional pg_class, try 2  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: Non-transactional pg_class, try 2  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-hackers
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?

> 2. Mark frozen databases specially somehow.
>    To mark databases frozen, we need a way to mark tables as frozen.
>    How do we do that?  As I explain below, this allows some nice
>    optimizations, but it's a very tiny can full of a huge amount of
>    worms.

Avoiding a vacuum pass over template0 once every 2 billion transactions
cannot be thought worthy of the amount of complexity and risk entailed
in the nontransactional-catalog thing.  Especially since in the normal
case those would be read-only passes (the tuples all being frozen already).

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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: "Truncated" tuples for tuple hash tables
Next
From: Alvaro Herrera
Date:
Subject: Re: Non-transactional pg_class, try 2