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

[Hiroshi Inoue]

Tom Lane wrote: > > Hiroshi Inoue <[EMAIL PROTECTED]> 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