Hi Jesper, > I'm not seeing this deadlock with just the WAL v8 patch applied. >
okay, Thanks for confirming that. I would like to update you that I am not able to reproduce this issue at my end. I suspect that the steps i am following might be slightly different than your's. Could you please have a look at steps mentioned below and confirm if there is something different that I am doing. Firstly, I am running the test-case on following git commit in head: <git-commmit> commit ba61a04bc7fefeee03416d9911eb825c4897c223 Author: Tom Lane <t...@sss.pgh.pa.us> Date: Thu Jan 19 19:52:13 2017 -0500 Avoid core dump for empty prepared statement in an aborted transaction. Brown-paper-bag bug in commit ab1f0c822: the old code here coped with null CachedPlanSource.raw_parse_tree, the new code not so much. Per report from Dave Cramer. </git-commit> On top of above commit, I have applied WAL v8 patch for hash index and MV v5 patch. Now, with an --enable-cassert build I am following below steps: 1) Created a 'test' database 2) psql -d test -f ~/ddl.sql where ddl.sql is, -- ddl.sql -- CREATE TABLE test AS SELECT generate_series(1, 10) AS id, 0 AS val; CREATE INDEX IF NOT EXISTS idx_id ON test USING hash (id); CREATE INDEX IF NOT EXISTS idx_val ON test USING hash (val); ANALYZE; -- ddl.sql -- 3) pgbench -M prepared -c 10 -j 10 -T 1800 -f ~/test.sql test where test.sql is, -- test.sql -- \set id random(1,10) \set val random(0,10) BEGIN; UPDATE test SET val = :val WHERE id = :id; COMMIT; -- test.sql -- Machine details are as follows: Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 128 On-line CPU(s) list: 0-127 Thread(s) per core: 2 Core(s) per socket: 8 Socket(s): 8 Also, It would be great if you could confirm as if you have been getting this issue repeatedly. Thanks. With Regards, Ashutosh Sharma EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers