On 2021/08/10 21:22, torikoshia wrote:
I have updated the patch in this way.
Thanks for updating the patch!
In this patch, getting the plan to the DO statement is as follows.
Looks good to me.
Any thoughts?
+ ereport(LOG_SERVER_ONLY,
+ (errmsg("plan of the query running on backend with PID %d
is:\n%s",
+ MyProcPid, es->str->data),
+ errhidestmt(true)));
Shouldn't we hide context information by calling errhidecontext(true)?
While "make installcheck" regression test was running, I repeated
executing pg_log_current_query_plan() and got the failure of join_hash test
with the following diff. This means that pg_log_current_query_plan() could
cause the query that should be completed successfully to fail with the error.
Isn't this a bug?
I *guess* that the cause of this issue is that ExplainNode() can call
InstrEndLoop() more than once unexpectedly.
------------------------------------------------------------------------------
$$
select count(*) from simple r join simple s using (id);
$$);
- initially_multibatch | increased_batches
-----------------------+-------------------
- f | f
-(1 row)
-
+ERROR: InstrEndLoop called on running node
+CONTEXT: PL/pgSQL function hash_join_batches(text) line 6 at FOR over EXECUTE
statement
rollback to settings;
-- parallel with parallel-oblivious hash join
savepoint settings;
@@ -687,11 +684,9 @@
left join (select b1.id, b1.t from join_bar b1 join join_bar b2 using
(id)) ss
on join_foo.id < ss.id + 1 and join_foo.id > ss.id - 1;
$$);
- multibatch
-------------
- t
-(1 row)
-
+ERROR: InstrEndLoop called on running node
+CONTEXT: parallel worker
+PL/pgSQL function hash_join_batches(text) line 6 at FOR over EXECUTE statement
rollback to settings;
-- single-batch with rescan, parallel-aware
savepoint settings;
------------------------------------------------------------------------------
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
