Ühel kenal päeval (esmaspäev, 7. veebruar 2005, 10:51-0500), kirjutas
Tom Lane:
> Hannu Krosing <hannu@tm.ee> writes:
> > As VACUUM is not something that can be rolled back, could we not make it
> > run completely outside transactions.
>
> No, because it has to be able to hold a table-level lock on the target
> table.
Does NON-FULL VACUUM release this lock when pausing when sleeping on
vacuum_cost_delay ?
If not, could it be made to release the lock and end current transaction
when going to sleep and start a new transaction and aquire the lock
again when waking up ?
> Besides, where did you get the idea that it can't be rolled back?
> The VACUUM FULL case, at least, has to go through huge pushups to be
> sure it is rollback-safe.
What are the semantics of ROLLBACKing a VACUUM FULL ? Will it restore
the dead tuples to their original positions ?
I assumed that it does its data-shuffling behind the scenes so that
changes done by it are invisible to others at the *logical* level.
If all the changes it does to internal data storage can be rolled back,
then I can't see how VACUUM FULL can work at all without requiring 2x
the filesize for the ROLLBACK.
Also, why must it be run outside of transaction block if it can be
rollbacked ?
--
Hannu Krosing <hannu@tm.ee>
