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: 3A344529.B7DAF1AA@tpf.co.jp (view raw or flat)
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 ?

Regards.
Hiroshi Inoue

In response to

Responses

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-2014 The PostgreSQL Global Development Group