Re: [COMMITTERS] pgsql/src/backend/commands (command.c vacuum.c)
От | Hiroshi Inoue |
---|---|
Тема | Re: [COMMITTERS] pgsql/src/backend/commands (command.c vacuum.c) |
Дата | |
Msg-id | 3A341902.7A3B30C@tpf.co.jp обсуждение исходный текст |
Ответ на | RE: [COMMITTERS] pgsql/src/backend/commands (command.c vacuum.c) ("Hiroshi Inoue" <Inoue@tpf.co.jp>) |
Ответы |
Re: [COMMITTERS] pgsql/src/backend/commands (command.c vacuum.c)
|
Список | pgsql-hackers |
Tom Lane wrote: > > "Hiroshi Inoue" <Inoue@tpf.co.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
В списке pgsql-hackers по дате отправления: