Re: [COMMITTERS] pgsql/src/backend/commands (command.c vacuum.c)

Tom Lane wrote:
>
> Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> writes:
> > Tom Lane wrote:
> >> Why not? The intermediate state *is valid*. We just haven't
> >> removed no-longer-referenced index and TOAST entries yet.
>
> > Do you mean *already committed* state has no problem and
> > VACUUM is always possible in the state ?
>
> Yes. Otherwise VACUUM wouldn't be crash-safe.
>

When VACUUM for a table starts, the transaction is not
committed yet of cource. After *commit* VACUUM has handled
heap/index tuples very carefully to be crash-safe before
7.1. Currently another vacuum could be invoked in the
already committed transaction. There has been no such
situation before 7.1. Yes,VACUUM isn't crash-safe now.

> > Hmmm,is keeping the lock on master table more important than
> > risking to break consistency ?
>
> I see no consistency risk here. I'd be more worried about potential
> risks from dropping the lock too soon.
>

Thers's no potential risk other than deadlock.
If we have to avoid deadlock we could acquire
the lock on master table first. Is there any
problem ?

Regards.
Hiroshi Inoue