From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-committers(at)lists(dot)postgresql(dot)org |
Subject: | Re: pgsql: SQL-standard function body |
Date: | 2021-04-08 06:25:16 |
Message-ID: | 93cd20a5-1d4a-6cc9-a70a-41a7c8c4d80a@eisentraut.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
On 08.04.21 01:06, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
>> On 2021-04-07 19:53:35 +0000, Peter Eisentraut wrote:
>>> SQL-standard function body
>
>> This is turning the BF red:
>> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=rhinoceros&dt=2021-04-07%2022%3A52%3A19
>> Might be force_parallel_mode=regress related.
>
> Yeah. On my machine, it's fine without force_parallel_mode and
> crashes with that. Looks like query text is not getting passed
> to the parallel worker in some cases.
There does not appear to be any indication in CreateQueryDesc() or for
es_sourceText that the query source text needs to be not NULL (unlike
PortalDefineQuery() for example). If we want that to be the case, an
assert in CreateQueryDesc() would be a straightforward way to catch
this. But for example code in CreateExecutorState() and
executor_errposition() is prepared to have es_sourceText be NULL, so
relative to that, the fix that Andres put into ExecInitParallelPlan() to
handle that as well seems appropriate.
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2021-04-08 06:35:41 | pgsql: Update Unicode data to CLDR 39 |
Previous Message | Tom Lane | 2021-04-08 06:16:30 | Re: pgsql: autovacuum: handle analyze for partitioned tables |