On 10/10/2014 05:08 PM, MauMau wrote: > From: "Craig Ringer" <cr...@2ndquadrant.com> >> It sounds like they've produced a test case, so they should be able to >> with a bit of luck. >> >> Or even better, send you the test case. > > I asked the user about this. It sounds like the relevant test case consists > of many scripts. He explained to me that the simplified test steps are: > > 1. initdb > 2. pg_ctl start > 3. Create 16 tables. Each of those tables consist of around 10 columns. > 4. Insert 1000 rows into each of those 16 tables. > 5. Launch 16 psql sessions concurrently. Each session updates all 1000 rows > of one table, e.g., session 1 updates table 1, session 2 updates table 2, > and so on. > 6. Repeat step 5 50 times. > > This sounds a bit complicated, but I understood that the core part is 16 > concurrent updates, which should lead to contention on xlog insert slots > and/or spinlocks.
I was able to reproduce this. I reduced wal_buffers to 64kB, and NUM_XLOGINSERT_LOCKS to 4 to increase the probability of the deadlock, and ran a test case as above on my laptop for several hours, and it finally hung. Will investigate... - Heikki -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
