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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Julien Rouhaud <rjuju123(at)gmail(dot)com>
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-05 22:59:59
Message-ID: 23541.1551826799@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

I wrote:
> In v10 and later, not so much:

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). 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.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Michael Paquier 2019-03-06 02:56:26 Re: BUG #15667: "could not truncate file" error caused deleted rows to become visible
Previous Message Tom Lane 2019-03-05 22:21:56 Re: BUG #15669: Error with unnest in PG 11 (ERROR: 0A000)