Re: Re: [COMMITTERS] pgsql: Only try to push down foreign joins if the user mapping OIDs mat

Поиск
Список
Период
Сортировка
От Ashutosh Bapat
Тема Re: Re: [COMMITTERS] pgsql: Only try to push down foreign joins if the user mapping OIDs mat
Дата
Msg-id CAFjFpRcGU+p7z99w6S0inMJcxPH02mtj3cWeYUDcz0txU1frLw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Re: [COMMITTERS] pgsql: Only try to push down foreign joins if the user mapping OIDs mat  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Re: [COMMITTERS] pgsql: Only try to push down foreign joins if the user mapping OIDs mat  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers


On Wed, Mar 16, 2016 at 2:14 AM, Robert Haas <robertmhaas@gmail.com> wrote:
On Tue, Mar 15, 2016 at 6:44 AM, Ashutosh Bapat
<ashutosh.bapat@enterprisedb.com> wrote:
> Here's patch which fixes the issue using Robert's idea.

Please at least check your patches with 'git diff --check'

Thanks.
 
before
submitting them.  And where it's not too much trouble, pgindent them.
Or at least make them look something like what pgindent would have
produced, instead of having the line lengths be all over the place.

Sorry. PFA the patch with git diff --check output fixed.
 

 -- change the session user to view_owner and execute the statement. Because of
 -- change in session user, the plan should get invalidated and created again.
--- While creating the plan, it should throw error since there is no
user mapping
--- available for view_owner.
+-- The join will not be pushed down since the joining relations do not have a
+-- valid user mapping.

Now what's going on here?  It seems to me that either postgres_fdw
requires a user mapping (in which case this ought to fail) or it
doesn't (in which case this ought to push the join down).  I don't
understand how working but not pushing the join down can ever be the
right behavior.


In 9.5, postgres_fdw allowed to prepare statements involving foreign tables without an associated user mapping as long as planning did not require the user mapping. Remember, planner would require user mapping in case use_remote_estimate is ON for that foreign table. The user mapping would be certainly required at the time of execution. So executing such a prepared statement would throw error. If somebody created a user mapping between prepare and execute, execute would not throw an error. A join can be pushed down only when user mappings associated with the joining relations are known and they match. But given the behavior of 9.5 we should let the prepare succeed, even if the join can not be pushed down because of unknown user mapping. Before this fix, the test was not letting the prepare succeed, which is not compliant with 9.5.

--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Kyotaro HORIGUCHI
Дата:
Сообщение: Re: Support for N synchronous standby servers - take 2
Следующее
От: Julien Rouhaud
Дата:
Сообщение: Re: Choosing parallel_degree