Re: BUG #15669: Error with unnest in PG 11 (ERROR: 0A000)

From: Julien Rouhaud <rjuju123(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andres Freund <andres(at)anarazel(dot)de>, thibaut(dot)madelaine(at)dalibo(dot)com, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: BUG #15669: Error with unnest in PG 11 (ERROR: 0A000)
Date: 2019-03-06 17:08:30
Message-ID: CAOBaU_bs7hbXxtvncLmfX34E4V8KQia6M8KSt4Lf_hapZKQtQQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Sorry for late answer,

On Wed, Mar 6, 2019 at 12:00 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> In v10 and later, not so much:

Ouch, I should have followed more closely the comments and code in the
dummy part.

> BTW, I forgot to clarify that in unpatched v11 and HEAD,
> this test case appears to work, but that's only because
> apply_scanjoin_target_to_paths is forgetting to install the
> ProjectSetPath that should be there (and then, because the outer
> query now realizes that the inner one is dummy, we don't construct
> a plan with any SRF calls in it, and thus avoid getting the error
> reported at the top of this thread).

I see.

> With the patch discussed
> so far, we get the same crummy plan as in v10.
>
> I spent a little bit of time musing over whether we could avoid
> inserting a ProjectSetPath at all, which would be nice because
> then we'd not emit a useless ProjectSet plan node. But that
> seems like it'd require replacing the SRF call with something
> else --- maybe a null constant of the right type --- and that
> opens up a large can of worms in terms of getting setrefs.c
> to not choke. I'm doubtful that it's worth the work at all,
> and I certainly wouldn't risk back-patching it.

I agree that the RelOptInfo new flag / IS_DUMMY_REL change solution is
the best solution. Let's hope there won't be too many extensions
relying on the old IS_DUMMY_REL() macro. I'll work on a new version
of the patch to implement it. In the meantime I'll add an entry for
this bug in the next commitfest to make sure we don't miss it.

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2019-03-06 17:28:27 BUG #15673: Stackbuilder SSL error on corporate network that uses SSL interdiction/resigning
Previous Message Jeff Janes 2019-03-06 15:46:48 Re: BUG #15671: The copy command does not load all the lines from a .csv file.