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 | 20150827174416.GJ2435@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
Re: missing locking in at least INSERT INTO view WITH CHECK |
Список | pgsql-hackers |
On 2015-08-27 18:37:10 +0100, Dean Rasheed wrote: > On 27 August 2015 at 12:18, Andres Freund <andres@anarazel.de> wrote: > >> > >> /* > >> + * If the view query contains any sublink subqueries, we should also > >> + * acquire locks on any relations they refer to. We know that there won't > >> + * be any subqueries in the range table or CTEs, so we can skip those, as > >> + * in AcquireRewriteLocks. > >> + */ > >> + if (viewquery->hasSubLinks) > >> + query_tree_walker(viewquery, acquireLocksOnSubLinks, NULL, > >> + QTW_IGNORE_RC_SUBQUERIES); > >> + > >> + /* > >> * Create a new target RTE describing the base relation, and add it to the > >> * outer query's rangetable. (What's happening in the next few steps is > >> * very much like what the planner would do to "pull up" the view into the > > > > These days this seems to require a context parameter being passed > > down. Other than that this patch still fixes the problem. > > > > Yes, I concur. It now needs an acquireLocksOnSubLinks_context with > for_execute = true, but otherwise it should work. Ok, I'll push that then, unless somebody else wants to do the honors. > I have a feeling that RLS might suffer from the same issue, but I > haven't looked yet. There's a similar issue there, yes: http://archives.postgresql.org/message-id/20150827124931.GD15922%40awork2.anarazel.de Are you thinking of that angle, or yet another one? Regards, Andres
В списке pgsql-hackers по дате отправления: