From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Assert failure on running a completed portal again |
Date: | 2024-12-09 18:16:52 |
Message-ID: | 3932492.1733768212@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I wrote:
> Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp> writes:
>> I guess planstate is removed due to the redundancy that this is included
>> in queryDesc. If so, I think we can also remove use_parallel_mode for the
>> same reason.
> Certainly there's a bit of aesthetic judgment involved here.
After thinking awhile longer, I'm coming around to the idea that
you're right and it'd be better to get rid of ExecutePlan's
use_parallel_mode argument. We clearly have to pass down count and
direction, and it's sensible to pass down operation, sendTuples,
and dest because ExecutorRun is involved with those to perform
dest-receiver startup and shutdown. But ExecutorRun has no real
concern with the parallelism decision, so it seems better to unify
that logic in one place.
I'll make that change before pushing.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andrey M. Borodin | 2024-12-09 18:26:02 | Re: [PATCH] Add sortsupport for range types and btree_gist |
Previous Message | Noah Misch | 2024-12-09 18:13:15 | Re: WARNING: missing lock on database "postgres" (OID 5) @ TID (0,4) |