Simon Riggs wrote:
> On Wed, 2005-11-16 at 08:31 +0000, Simon Riggs wrote:
> > All tuples might be frozen or might not be, the point is you don't know.
> > That's why you can't use FrozenTransactionId.
> Thinking some more, when initdb issues VACUUM FREEZE we know for certain
> that nobody else is issuing commands against the database at that point,
> which is equivalent to a table lock. So we should be able to have a
> VACUUM FREEZE detect that and if so, set FrozenTransactionId.
>
> In normal concurrent running, I would like VACUUM FREEZE to issue a full
> table SHARE lock to ensure that we can set FrozenTransactionId for that
> also. Otherwise we will not be able to move frozen tables to read only
> media.
You missed one point however. Even if VACUUM FREEZE freezes all tuples,
any transaction following that one is able to insert non-frozen tuples
into the table. At that instant, having marked the table with Frozen is
bogus, no matter what amount of locks you took on it.
We can only do that (mark the table Frozen) if and only if all following
transactions are forced to mark the table "unfrozen" as soon as they
change it. Are we going to do that?
Note that trying to unfreeze a table might be difficult -- we might need
to obtain a lock on pg_class after we have opened and locked the target
relation, leading to possible deadlock on INSERT. Yikes.
--
Alvaro Herrera Valdivia, Chile ICBM: S 39º 49' 17.7", W 73º 14' 26.8"
"Ciencias políticas es la ciencia de entender por qué
los políticos actúan como lo hacen" (netfunny.com)