Re: missing locking in at least INSERT INTO view WITH CHECK
От | Andres Freund |
---|---|
Тема | Re: missing locking in at least INSERT INTO view WITH CHECK |
Дата | |
Msg-id | 20131024172810.GE18793@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: missing locking in at least INSERT INTO view WITH CHECK (Dean Rasheed <dean.a.rasheed@gmail.com>) |
Ответы |
Re: missing locking in at least INSERT INTO view WITH CHECK
|
Список | pgsql-hackers |
On 2013-10-23 21:20:58 +0100, Dean Rasheed wrote: > On 23 October 2013 21:08, Andres Freund <andres@2ndquadrant.com> wrote: > > On 2013-10-23 20:51:27 +0100, Dean Rasheed wrote: > >> Hmm, my first thought is that rewriteTargetView() should be calling > >> AcquireRewriteLocks() on viewquery, before doing too much with it. > >> There may be sub-queries in viewquery's quals (and also now in its > >> targetlist) and I don't think the relations referred to by those > >> sub-queries are getting locked. > > > > Well, that wouldn't follow the currently documented rule ontop > > of QueryRewrite: > > * NOTE: the parsetree must either have come straight from the parser, > > * or have been scanned by AcquireRewriteLocks to acquire suitable locks. > > > > It might still be the right thing to do, but it seems suspicious that > > the rules need to be tweaked like that. > > > > Well it matches what already happens in other places in the rewriter > --- see rewriteRuleAction() and ApplyRetrieveRule(). It's precisely > because the rule action's query hasn't come from the parser that it > needs to be processed in this way. I really don't know that are of code that well, fortunately I never had to wade around it much so far... Reading your explanation and a bit of the code your plan sound sane. Are you going to propose a patch? Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: