On Tue, Nov 17, 2015 at 1:21 AM, Bert <bier...@gmail.com> wrote: > Hey, > > I've just pulled and compiled the new code. > I'm running a TPC-DS like test on different PostgreSQL installations, but > running (max) 12queries in parallel on a server with 12cores. > I've configured max_parallel_degree to 2, and I get messages that backend > processes crash. > I am running the same test now with 6queries in parallel, and parallel > degree to 2, and they seem to work. for now. :) > > This is the output I get in /var/log/messages > Nov 16 20:40:05 woludwha02 kernel: postgres: segfault at > 7fa3437bf104 ip 0000000000490b56 sp 00007ffdf2f083a0 error 6 in > postgres[400000+5b5000] > > Thanks for reporting the issue.
I think whats going on here is that when any of the session doesn't get any workers, we shutdown the Gather node which internally destroys the dynamic shared memory segment as well. However the same is needed as per current design for doing scan by master backend as well. So I think the fix would be to just do shutdown of workers which actually won't do anything in this scenario. I have tried to reproduce this issue with a simpler test case as below: Create two tables with large data: CREATE TABLE t1(c1, c2) AS SELECT g, repeat('x', 5) FROM generate_series(1, 10000000) g; CREATE TABLE t2(c1, c2) AS SELECT g, repeat('x', 5) FROM generate_series(1, 1000000) g; Set max_worker_processes = 2 in postgresql.conf Session-1 set max_parallel_degree=4; set parallel_tuple_cost=0; set parallel_setup_cost=0; Explain analyze select count(*) from t1 where c1 > 10000; Session-2 set max_parallel_degree=4; set parallel_tuple_cost=0; set parallel_setup_cost=0; Explain analyze select count(*) from t2 where c1 > 10000; The trick to reproduce is that the Explain statement in Session-2 needs to be executed immediately after Explain statement in Session-1. Attached patch fixes the issue for me. I think here we can go for somewhat more invasive fix as well which is if the statement didn't find any workers, then reset the dsm and also reset the execution tree (which in case of seq scan means clear the parallel scan desc and may be few more fields in scan desc) such that it performs seq scan. I am not sure how future-proof such a change would be, because resetting some of the fields in execution tree and expecting it to work in all cases might not be feasible for all nodes. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
Description: Binary data
-- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers