From: | Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>, Andres Freund <andres(at)anarazel(dot)de>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Re: [COMMITTERS] pgsql: Only try to push down foreign joins if the user mapping OIDs mat |
Date: | 2016-03-16 08:10:40 |
Message-ID: | CAFjFpRcGU+p7z99w6S0inMJcxPH02mtj3cWeYUDcz0txU1frLw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
On Wed, Mar 16, 2016 at 2:14 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Tue, Mar 15, 2016 at 6:44 AM, Ashutosh Bapat
> <ashutosh(dot)bapat(at)enterprisedb(dot)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
Attachment | Content-Type | Size |
---|---|---|
pg_no_um.patch | text/x-diff | 18.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Teodor Sigaev | 2016-03-16 13:50:35 | pgsql: Improve script generating unaccent rules |
Previous Message | Robert Haas | 2016-03-15 22:08:37 | pgsql: Fix typos. |
From | Date | Subject | |
---|---|---|---|
Next Message | Julien Rouhaud | 2016-03-16 08:15:47 | Re: Choosing parallel_degree |
Previous Message | Kyotaro HORIGUCHI | 2016-03-16 07:48:33 | Re: Support for N synchronous standby servers - take 2 |