On Wed, Apr 12, 2017 at 10:30 PM, Tom Lane wrote:
> Amit Kapila writes:
>> On Wed, Apr 12, 2017 at 12:40 AM, Tom Lane wrote:
>>> Anyone want to draft a patch for this?
>
>> Please find patch attached based on above discussion.
>
> This patch seems fairly incomplete: you can't just whack around m
Amit Kapila writes:
> On Wed, Apr 12, 2017 at 12:40 AM, Tom Lane wrote:
>> Anyone want to draft a patch for this?
> Please find patch attached based on above discussion.
This patch seems fairly incomplete: you can't just whack around major data
structures like PlannedStmt and PlannerGlobal with
Amit Kapila writes:
> On Wed, Apr 12, 2017 at 12:40 AM, Tom Lane wrote:
>> Anyone want to draft a patch for this?
> Please find patch attached based on above discussion.
Thanks, I'll look at this later today.
regards, tom lane
--
Sent via pgsql-hackers mailing list (
On Wed, Apr 12, 2017 at 12:40 AM, Tom Lane wrote:
> Amit Kapila writes:
>
>> However, the worker will
>> never execute such a plan as we don't generate a plan where unsafe
>> sublan/initplan is referenced in the node passed to the worker. If we
>> want to avoid passing parallel-unsafe subplans t
On Tue, Apr 11, 2017 at 10:02 PM, Tom Lane wrote:
> Ashutosh Bapat writes:
>> On Tue, Apr 11, 2017 at 8:11 PM, Tom Lane wrote:
>>> OK. I was trying to be noninvasive, but this does look more sensible.
>>> I think this might read better if we inverted the test (so that
>>> the outer-join-joincla
On Wed, Apr 12, 2017 at 12:40 AM, Tom Lane wrote:
> Amit Kapila writes:
>
>> I think there is a possibility of doing ExecInitNode in a parallel
>> worker for a parallel-unsafe subplan, because we pass a list of all
>> the sublans stored in planned statement.
>
> It's more than a possibility. If
Amit Kapila writes:
> On Tue, Apr 11, 2017 at 5:29 AM, Tom Lane wrote:
>> I think the fact that we see this problem at all may indicate an
>> oversight in commit 5e6d8d2bbbcace304450b309e79366c0da4063e4 ("Allow
>> parallel workers to execute subplans"). If the worker were to actually
>> run the
Ashutosh Bapat writes:
> On Tue, Apr 11, 2017 at 8:11 PM, Tom Lane wrote:
>> OK. I was trying to be noninvasive, but this does look more sensible.
>> I think this might read better if we inverted the test (so that
>> the outer-join-joinclause-must-be-pushable case would come first).
> Ok. In fa
On Tue, Apr 11, 2017 at 8:11 PM, Tom Lane wrote:
> Ashutosh Bapat writes:
>> On Tue, Apr 11, 2017 at 3:53 AM, Tom Lane wrote:
>> +* there is no need for EPQ recheck at a join (and Vars or Aggrefs in
>> +* the qual might not be available locally anyway).
>
>> I am not sure whether
Andreas Seltenreich writes:
> I see the above ERROR logged a lot when testing master at eef8c0069e
> with a postgres_fdw around. Below is a recipe to reproduce it on top of
> the regression DB.
I've pushed a fix that should get you past that problem, although
I suspect we still have some issues
Ashutosh Bapat writes:
> On Tue, Apr 11, 2017 at 3:53 AM, Tom Lane wrote:
> +* there is no need for EPQ recheck at a join (and Vars or Aggrefs in
> +* the qual might not be available locally anyway).
> I am not sure whether EPQ checks make sense for an upper relation, esp. a
> gr
On Tue, Apr 11, 2017 at 3:53 AM, Tom Lane wrote:
> I wrote:
>> Apparently, postgres_fdw is trying to store RestrictInfos in the
>> fdw_private field of a ForeignScan node. That won't do; those aren't
>> supposed to be present in a finished plan tree, so there's no readfuncs.c
>> support for them
On Tue, Apr 11, 2017 at 3:53 AM, Tom Lane wrote:
> I wrote:
>> Apparently, postgres_fdw is trying to store RestrictInfos in the
>> fdw_private field of a ForeignScan node. That won't do; those aren't
>> supposed to be present in a finished plan tree, so there's no readfuncs.c
>> support for them
On Tue, Apr 11, 2017 at 5:29 AM, Tom Lane wrote:
> I wrote:
>> (BTW, I've not yet looked to see if this needs to be back-ported.)
>
> postgres_fdw will definitely include RestrictInfos in its fdw_private
> list in 9.6. However, I've been unable to provoke a visible failure.
> After some rooting a
I wrote:
> (BTW, I've not yet looked to see if this needs to be back-ported.)
postgres_fdw will definitely include RestrictInfos in its fdw_private
list in 9.6. However, I've been unable to provoke a visible failure.
After some rooting around, the reason seems to be that:
1. postgres_fdw doesn't
I wrote:
> Apparently, postgres_fdw is trying to store RestrictInfos in the
> fdw_private field of a ForeignScan node. That won't do; those aren't
> supposed to be present in a finished plan tree, so there's no readfuncs.c
> support for them (and we're not adding it).
> Don't know if this is a ne
Andreas Seltenreich writes:
> regression=> select (select max(result) from fdw_postgres.num_result) from
> tt0;
> ERROR: badly formatted node string "RESTRICTINFO :clause {NULLTEST :"...
> CONTEXT: parallel worker
Apparently, postgres_fdw is trying to store RestrictInfos in the
fdw_private fie
Hi,
I see the above ERROR logged a lot when testing master at eef8c0069e
with a postgres_fdw around. Below is a recipe to reproduce it on top of
the regression DB.
regards,
Andreas
create extension postgres_fdw;
create server myself foreign data wrapper postgres_fdw;
create schema fdw_postgres;
18 matches
Mail list logo
