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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-12-11 00:08:35 | Re: [COMMITTERS] pgsql/src/backend/commands (command.c vacuum.c) |
Previous Message | momjian | 2000-12-10 23:54:29 | pgsql/src/interfaces/odbc (psqlodbc.h) |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-12-11 00:08:35 | Re: [COMMITTERS] pgsql/src/backend/commands (command.c vacuum.c) |
Previous Message | Bruce Momjian | 2000-12-10 23:53:11 | Re: RFC C++ Interface |