Re: Revitalising VACUUM FULL for 8.3

On Thu, 2007-03-01 at 13:56, Simon Riggs wrote:
> > Wouldn't this be deadlock prone ? What if a non-utility transaction
> > (which could even be started before the vacuum full) blocks on the table
> > being vacuumed, then if the vacuum wants to wait until all non-utility
> > transactions finish will deadlock.
>
> Exactly the same as CREATE INDEX CONCURRENTLY, which has a much more
> frequent use case than VACUUM FULL does, even after I've made the
> proposed changes.
>
> The situation, as I understand it, would be that the utility command
> waits on another transaction to complete. As soon as that other
> transaction touches the locked table it will detect a simple deadlock
> and the non-utility statement will abort.

Fair enough.

> > > The utility transaction concept would make new VACUUM FULL MVCC-safe and
> > > would also make most executions of CLUSTER MVCC-safe also (the implicit
> > > top-level transaction cases).
> >
> > Making cluster MVCC-safe will kill my back-door of clustering a hot
> > table while I run a full DB backup.
>
> Wow. I'll take that as a request for a NOWAIT option on utility
> commands, rather than a suggestion that we shouldn't strive to make
> things safe in the default case.

Yes please... if the current behavior is possible to be triggered (by
that NOWAIT for eg.), it would be actually good to have the MVCC
behavior as default.

Thanks,
Csaba.