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
vacuum freeze. I like that more, than changing stuff that is otherwise
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
        - 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, 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.


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Reply via email to