Re: ALTER TABLE SET STATISTICS requires AccessExclusiveLock
От | Bruce Momjian |
---|---|
Тема | Re: ALTER TABLE SET STATISTICS requires AccessExclusiveLock |
Дата | |
Msg-id | 201002221532.o1MFWHi23562@momjian.us обсуждение исходный текст |
Ответ на | Re: ALTER TABLE SET STATISTICS requires AccessExclusiveLock (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: ALTER TABLE SET STATISTICS requires
AccessExclusiveLock
|
Список | pgsql-hackers |
Simon Riggs wrote: > On Mon, 2009-10-19 at 12:56 -0300, Alvaro Herrera wrote: > > Simon Riggs wrote: > > > > > > On Fri, 2009-08-07 at 15:58 -0400, Alvaro Herrera wrote: > > > > Tom Lane wrote: > > > > > Peter Eisentraut <peter_e@gmx.net> writes: > > > > > > Is there a good reason for $subject, other than that the code is entangled > > > > > > with other ALTER TABLE code? > > > > > > > > > > I think it could be lower, but it would take nontrivial restructuring of > > > > > the ALTER TABLE support. In particular, consider what happens when you > > > > > have a list of subcommands that don't all require the same lock level. > > > > > I think you'd need to scan the list and find the highest required lock > > > > > level before starting ... > > > > > > > > IIRC there was a patch from Simon to address this issue, but it had some > > > > holes which he didn't have time to close, so it sank. Maybe this can be > > > > resurrected and fixed. > > > > > > I was intending to finish that patch in this release cycle. > > > > Since you're busy with Hot Standby, any chance you could pass it on? > > If you'd like. It's mostly finished, just one last thing to finish: > atomic changes to pg_class via an already agreed API. I assume this did not get done for 9.0. Do we want a TODO item? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.comPG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do + If your life is a hard drive,Christ can be your backup. +
В списке pgsql-hackers по дате отправления: