Re: BUG #15669: Error with unnest in PG 11 (ERROR: 0A000) - Mailing list pgsql-bugs

From Julien Rouhaud
Subject Re: BUG #15669: Error with unnest in PG 11 (ERROR: 0A000)
Date
Msg-id CAOBaU_ZE6+9YBL8htVC=hvV7Wv=Dd3i_Ze+NzW+ESuWpSsjoOw@mail.gmail.com
Whole thread Raw
In response to Re: BUG #15669: Error with unnest in PG 11 (ERROR: 0A000)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: BUG #15669: Error with unnest in PG 11 (ERROR: 0A000)
List pgsql-bugs
On Tue, Mar 5, 2019 at 6:29 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Julien Rouhaud <rjuju123@gmail.com> writes:
>
> > It seems to be due to 11cf92f6e2e which bypass adjust_paths_for_srfs()
> > in case of dummy rel.  I'm not familiar with that this code, but
> > attached patch seems to fix the issue without breaking regression
> > tests.
>
> Hm, yeah, that function is definitely a few bricks shy of a load.
> The amount of code it's bypassing for the dummy-rel case is pretty
> scary.  While it doesn't look like anything except the SRF case is
> actively broken, there's a lot of room there for somebody to insert
> new code and not notice that they need to fix the dummy-rel path
> as well.  Having to duplicate the adjust_paths_for_srfs call doesn't
> bode well for the future.
>
> I'm inclined to fix it by not having the early-return path, but rather
>
>         if (is_dummy_rel)
>         {
>                 // minimum possible amount of code here
>         }
>         else
>         {
>                 // minimum possible amount of code here, too
>         }
>
>         // maximum possible amount of code here

That makes sense, I was also dubious of the previous fix.  Attached v3
reorganizes the code this way.  The adjust_paths_for_srfs call is now
done after everything else.  AFAICT it shouldn't matter, and
regression tests still seem happy with it.

Attachment

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #15669: Error with unnest in PG 11 (ERROR: 0A000)
Next
From: Tom Lane
Date:
Subject: Re: BUG #15669: Error with unnest in PG 11 (ERROR: 0A000)