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
In response to
pgsql-hackers by date
|Next:||From: Tim Perdue||Date: 2000-12-11 05:26:35|
|Subject: SourceForge & Postgres|
|Previous:||From: Bruce Momjian||Date: 2000-12-11 02:06:46|
|Subject: Re: Re: COPY BINARY file format proposal|
pgsql-committers by date
|Next:||From: ishii||Date: 2000-12-11 05:00:19|
|Subject: pgsql/src/backend/utils/adt (like.c)|
|Previous:||From: momjian||Date: 2000-12-11 01:44:37|
|Subject: pgsql/doc (TODO)|