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 ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster