Bug 131 - two concurrent subscribe sets can deadlock each other
Summary: two concurrent subscribe sets can deadlock each other
Status: NEW
Alias: None
Product: Slony-I
Classification: Unclassified
Component: slonik (show other bugs)
Version: 2.0
Hardware: All Linux
: low major
Assignee: Slony Bugs List
URL:
Depends on:
Blocks:
 
Reported: 2010-05-31 13:29 UTC by Steve Singer
Modified: 2010-05-31 13:29 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Steve Singer 2010-05-31 13:29:33 UTC
I have not verified that something else isn't going on at the same time to contribute to this deadlock.


If I launch two slonik processes concurrently to subscribe nodes 2 and 3 to set 1 from origin 1.  I seem to sometimes get deadlock notification from Pg.

It is also possible that the slonik doing the subscribe set is deadlocking with a slon set confiruration information.  Either way I wouldn't expect PG detected deadlock situtations,  I thought that was the point of the configuration lock.





enThread_1: queue event 3,5000000003 STORE_PATH
2010-05-31 16:12:27,661 [db2 stdout] DEBUG info.slony.clustertest.testcoordinator.slony.SlonLauncher db2 - 2010-05-31 16:12:27 EDTDEBUG2 remoteWorkerThread_3: Received event #3 from 5000000001 type:STORE_PATH
2010-05-31 16:12:27,665 [db2 stdout] DEBUG info.slony.clustertest.testcoordinator.slony.SlonLauncher db2 - 2010-05-31 16:12:27 EDTDEBUG2 remoteWorkerThread_1: Received event #1 from 5000000013 type:SET_ADD_TABLE
2010-05-31 16:12:27,711 [slonik subscribe stderr] ERROR info.slony.clustertest.testcoordinator.slony.SlonikScript slonik subscribe  - <stdin>:13: PGRES_FATAL_ERROR select "_disorder_replica".subscribeSet(1, 1, 3, 't', 'f');  - ERROR:  deadlock detected
2010-05-31 16:12:27,711 [slonik subscribe stderr] ERROR info.slony.clustertest.testcoordinator.slony.SlonikScript slonik subscribe  - DETAIL:  Process 32107 waits for ExclusiveLock on relation 413672 of database 412926; blocked by process 32010.
2010-05-31 16:12:27,711 [slonik subscribe stderr] ERROR info.slony.clustertest.testcoordinator.slony.SlonikScript slonik subscribe  - Process 32010 waits for ExclusiveLock on relation 413672 of database 412926; blocked by process 32107.
2010-05-31 16:12:27,711 [slonik subscribe stderr] ERROR info.slony.clustertest.testcoordinator.slony.SlonikScript slonik subscribe  - CONTEXT:  SQL statement "LOCK TABLE _disorder_replica.sl_event IN EXCLUSIVE MODE; INSERT INTO _disorder_replica.sl_event (ev_origin, ev_seqno, ev_timestamp, ev_snapshot, ev_type, ev_data1, ev_data2, ev_data3, ev_data4, ev_data5, ev_data6, ev_data7, ev_data8) VALUES ('1', nextval('_disorder_replica.sl_event_seq'), now(), "pg_catalog".txid_current_snapshot(), $1, $2, $3, $4, $5, $6, $7, $8, $9); SELECT currval('_disorder_replica.sl_event_seq');"
2010-05-31 16:12:27,711 [slonik subscribe stderr] ERROR info.slony.clustertest.testcoordinator.slony.SlonikScript slonik subscribe  - PL/pgSQL function "subscribeset" line 59 at assignment
2010-05-31 16:12:27,711 [slonik subscribe  stdout] DEBUG info.slony.clustertest.testcoordinator.slony.SlonikScript slonik subscribe  - <stdin>:12: subscribing to set
2010-05-31 16:12:27,713 [main] INFO  info.slony.clustertest.testcoordinator.TestResult  - slonik exit status:fail:255.0,0.0



This is with slony 2.0.4 RC1 running against postgresql 8.3.9