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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [PATCHES] Non-transactional pg_class, try 2
Дата
Msg-id 23140.1151357193@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [PATCHES] Non-transactional pg_class, try 2  (Alvaro Herrera <alvherre@commandprompt.com>)
Ответы Re: Non-transactional pg_class, try 2  (Alvaro Herrera <alvherre@commandprompt.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: "Truncated" tuples for tuple hash tables
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Non-transactional pg_class, try 2