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 00:00:03
Message-ID: 3A341902.7A3B30C@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:
> > There's no command other than VACUUM which continues to
> > access table/index after *commit*. We couldn't process
> > significant procedures in such an already commiitted state,
> > could we ?
> 
> 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 ?
Is VACUUM such a trivial job ?

> > What's wrong with vacuuming master and the toast table in
> > separate transactions ?
> 
> You'd have to give up the lock on the master table if there were
> a true commit.  I don't want to do that ... especially not when
> I don't believe there is a problem to fix.
> 

Hmmm,is keeping the lock on master table more important than
risking to break consistency ?

Regards.
Hiroshi Inoue

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2000-12-11 00:08:35
Subject: Re: [COMMITTERS] pgsql/src/backend/commands (command.c vacuum.c)
Previous:From: Bruce MomjianDate: 2000-12-10 23:53:11
Subject: Re: RFC C++ Interface

pgsql-committers by date

Next:From: Tom LaneDate: 2000-12-11 00:08:35
Subject: Re: [COMMITTERS] pgsql/src/backend/commands (command.c vacuum.c)
Previous:From: momjianDate: 2000-12-10 23:54:29
Subject: pgsql/src/interfaces/odbc (psqlodbc.h)

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