On Wed, 2005-11-16 at 08:31 +0000, Simon Riggs wrote:
> On Tue, 2005-11-15 at 21:58 -0300, Alvaro Herrera wrote:
> > In fact there's no problem because in D, just like in template1, all
> > tuples are frozen. How should we mark this on the catalogs? I don't
> > see any way.
>
> All tuples might be frozen or might not be, the point is you don't know.
> That's why you can't use FrozenTransactionId.
>
> > > Perhaps we should reinstate VACUUM FULL FREEZE to do just a FREEZE with
> > > a table lock and skip all that moving data around.
> >
> > Doesn't work either because of the argument above.
> >
> > What about assuming that if somebody executes a database-wide FREEZE, he
> > knows what he is doing and thus we can mark datminxid as
> > FrozenTransactionId?
>
> If you lock the table before FREEZE then you will guarantee that all
> rows will be frozen and you really can then set FrozenTransactionId.
>
> Making VACUUM FREEZE take full table locks seems like a very useful
> thing to me, and it would solve your problems also.
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.
Best Regards, Simon Riggs
