On Thu, Oct 15, 2015 at 11:45 PM, Amit Kapila <amit.kapil...@gmail.com> wrote: > On Thu, Oct 15, 2015 at 5:39 PM, Haribabu Kommi <kommi.harib...@gmail.com> > wrote: >> >> >> >> On Thu, Oct 15, 2015 at 6:32 PM, Amit Kapila <amit.kapil...@gmail.com> >> wrote: >> > On Wed, Oct 14, 2015 at 3:29 AM, Robert Haas <robertmh...@gmail.com> >> > wrote: >> > I think this got messed up while rebasing on top of Gather node >> > changes, but nonetheless, I have changed it such that PartialSeqScan >> > node handling is after SeqScan. >> >> Currently, the explain analyze of parallel seq scan plan is not showing >> the allocated number of workers >> including the planned workers.I feel this information is good for users in >> understanding the performance >> difference that is coming with parallel seq scan. It may be missed in >> recent patch series. It was discussed >> in[1]. >> > > I am aware of that and purposefully kept it for a consecutive patch. > There are other things as well which I have left out from this patch > and those are: > a. Early stop of executor for Rescan purpose > b. Support of pushdown for plans containing InitPlan and SubPlans > > Then there is more related work like > a. Support for prepared statements >
OK. During the test with latest patch, I found a dead lock between worker and backend on relation lock. To minimize the test scenario, I changed the number of pages required to start one worker to 1 and all parallel cost parameters as zero. Backend is waiting for the tuples from workers, workers are waiting on lock of relation. Attached is the sql script that can reproduce this issue. Regards, Hari Babu Fujitsu Australia
parallel_hang_with_cluster.sql
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
