On Mon, 2006-06-26 at 16:54 -0400, Alvaro Herrera wrote:
> > > Another optimization: if we are sure that unfreezing works, we can
> even
> > > mark a table as frozen in a postmaster environment, as long as we
> take
> > > an ExclusiveLock on the table. Thus we know that the vacuum is
> the sole
> > > transaction concurrently accessing the table; and if another
> transaction
> > > comes about and writes something after we're finished, it'll
> correctly
> > > unfreeze the table and all is well.
> >
> > Why not just have a command to FREEZE and UNFREEZE an object? It can
> > hold an ExclusiveLock, avoiding all issues. Presumably FREEZE and
> > UNFREEZE are rare commands?
>
> Ok, if I'm following you here, your point is that FREEZE'ing a table
> sets the relminxid to FrozenXid, and UNFREEZE removes that; and also,
> in
> between, no one can write to the table?
>
> This seems to make sense. However, I'm not very sure about the
> FREEZE'ing operation, because we need to make sure the table is really
> frozen. So we either scan it, or we make sure something else already
> scanned it; to me what makes the most sense is having a VACUUM option
> that would do the freezing (and a separate command to do the
> unfreezing).
Sounds like we're in step here:
VACUUM FREEZE
-- works at either table or database level
-- takes ExclusiveLock, reads all blocks of a table, freezing rows
-- once complete, all write operations are prevented until...
ALTER TABLE xxx UNFREEZE;
ALTER DATABASE xxx UNFREEZE;
-- takes AccessExclusiveLock, allows writes again
CREATE DATABASE automatically does unfreeze after template db copy
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.
Not sure where pg_class_nt comes in here though, even though I think I
still want it.
-- Simon Riggs EnterpriseDB http://www.enterprisedb.com
