From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: SQL-standard function body |
Date: | 2021-04-08 05:27:59 |
Message-ID: | 20210408052759.7bmyawm4djnrux6y@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2021-04-08 01:16:02 -0400, Tom Lane wrote:
> Michael Paquier <michael(at)paquier(dot)xyz> writes:
> > On Wed, Apr 07, 2021 at 04:22:17PM -0400, Tom Lane wrote:
> >> Buildfarm suggests this has some issues under force_parallel_mode.
> >> I'm wondering about missed fields in outfuncs/readfuncs, or the like.
>
> > The problem looks a bit more fundamental to me, as there seems to be
> > some confusion with the concept of what should be the query string
> > when it comes to prosqlbody with a parallel run, as it replaces prosrc
> > in some cases where the function uses SQL as language. If the
> > buildfarm cannot be put back to green, could it be possible to revert
> > this patch?
>
> Andres pushed a stopgap fix.
Let's hope that it does fix it on the BF as well. One holdup was that
check-world didn't succeed with force_parallel_mode=regress even after
the fix - but that turned out to be the fault of
commit 5fd9dfa5f50e4906c35133a414ebec5b6d518493 (HEAD)
Author: Bruce Momjian <bruce(at)momjian(dot)us>
Date: 2021-04-07 13:06:47 -0400
Move pg_stat_statements query jumbling to core.
et al.
> We might end up reverting the patch altogether for v14, but I don't
> want to be hasty. This should be enough to let people take advantage
> of the last few hours before feature freeze.
Yea, I think it'd be good to make that decision after a decent night of
sleep or two. And an actual look at the issues the patch might (or might
not) have.
Independent of this patch, it might be a good idea to have
ExecInitParallelPlan() be robust against NULL querystrings. Places like
executor_errposition() are certainly trying to be...
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2021-04-08 05:33:31 | Re: ModifyTable overheads in generic plans |
Previous Message | Andrey V. Lepikhov | 2021-04-08 05:24:22 | Re: Increase value of OUTER_VAR |