Skip site navigation (1) Skip section navigation (2)

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

From: Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jan Wieck <wieck(at)hub(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [COMMITTERS] pgsql/src/backend/commands (command.c vacuum.c)
Date: 2000-12-11 03:08:25
Message-ID: (view raw or whole thread)
Lists: pgsql-committerspgsql-hackers
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 ?

Hiroshi Inoue

In response to


pgsql-hackers by date

Next:From: Tim PerdueDate: 2000-12-11 05:26:35
Subject: SourceForge & Postgres
Previous:From: Bruce MomjianDate: 2000-12-11 02:06:46
Subject: Re: Re: COPY BINARY file format proposal

pgsql-committers by date

Next:From: ishiiDate: 2000-12-11 05:00:19
Subject: pgsql/src/backend/utils/adt (like.c)
Previous:From: momjianDate: 2000-12-11 01:44:37
Subject: pgsql/doc (TODO)

Privacy Policy | About PostgreSQL
Copyright © 1996-2015 The PostgreSQL Global Development Group