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

Very nice explanation, thanks Alvaro.

> 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.
>
> Marking a Table Frozen
> ======================
>
> Marking a table frozen is simple as setting relminxid =
> FrozenXid for a table. As explained above, this cannot be
> done in a regular postmaster environment, because a
> concurrent transaction could be doing nasty stuff to a table.
> So we can do it only in a standalone backend.

Unless you lock the table exclusively during vacuum, that could be done
with
vacuum freeze. I like that more, than changing stuff that is otherwise
completely
frozen/static. (I see you wrote that below)

> On the other hand, a "frozen" table must be marked with
> relminxid = a-regular-Xid as soon as a transaction writes
> some tuples on it. Note that this "unfreezing" must take
> place even if the offending transaction is aborted, because
> the Xid is written in the table nevertheless and thus it
> would be incorrect to lose the unfreezing.

The other idea was to need a special unfreeze command ...

>
> This is how pg_class_nt came into existence -- it would be a
> place where information about a table would be stored and not
> subject to the rolling back of the transaction that wrote it.

Oh, that puts it in another league, since it must guarantee commit.
I am not sure we can do that. The previous discussion was about
concurrency and data that was not so important like tuple count.

In short:
- I'd start with #1 (no relminxid = FrozenXid) like Tom
suggested
- and then implement FREEZE/UNFREEZE with exclusive locks
like Simon wrote (so it does not need pg_class_nt) and use that
for the templates.

Simon wrote:
> Suggest that we prevent write operations on Frozen tables by revoking
all INSERT, UPDATE or DELETE rights held, then enforcing a check during
GRANT to prevent them being re-enabled. Superusers would need to check
every time. If we dont do this, then we will have two contradictory
states marked in the catalog - privilges saying Yes and freezing saying
No.

No, I'd not mess with the permissions and return a different error when
trying to
modify a frozen table. (It would also be complicated to unfreeze after
create database)
We should make it clear, that freezing is no replacement for revoke.

Andreas