<html><body><div style="color:#000; background-color:#fff; font-family:times new roman, new york, times, serif;font-size:12pt"><div><span>Actually <br></span></div><div><br><span></span></div><div><span>With 2.0 stable, I've noticed that a "SUBSCRIBE SET" and a "WAIT FOR EVENT"</span></div><div><br><span></span></div><div><span>with PostgreSQL 8.4, I could have a deadlock done by a <br></span></div><div><br><span></span></div><div><span>2011-09-20 04:53:59 EDTDETAIL:&nbsp; Process 17710 waits for ExclusiveLock on relation 4867429 of database 4326133; blocked by process 9665.<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Process 9665 waits for AccessExclusiveLock on relation 4867482 of database 4326133; blocked by process 17710.<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Process 17710: select "_mycluster".subscribeSet(27, 1, 2, 't', 'f');<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Process 9665: select "_mycluster".cleanupEvent('240
 minutes'::interval, 'false'::boolean);<br>2011-09-20 04:53:59 EDTHINT:&nbsp; See server log for query details.<br>2011-09-20 04:53:59 EDTCONTEXT:&nbsp; SQL statement "LOCK TABLE _mycluster.sl_event IN EXCLUSIVE MODE; INSERT INTO _mycluster.sl_event (ev_origin, ev_seqno, ev_timestamp, ev_snapshot, ev_type, ev_data1, ev_data2, ev_data3, ev_data4, ev_data<br>5, ev_data6, ev_data7, ev_data8) VALUES ('1', nextval('_mycluster.sl_event_seq'), now(), "pg_catalog".txid_current_snapshot(), $1, $2, $3, $4, $5, $6, $7, $8, $9); SELECT currval('_mycluster.sl_event_seq');"<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PL/pgSQL function "subscribeset" line 64 at assignment<br>2011-09-20 04:53:59 EDTSTATEMENT:&nbsp; select "_mycluster".subscribeSet(27, 1, 2, 't', 'f');<br></span></div><div><span><br></span></div><div><span>or<br></span></div><div><span><br></span></div><div><span>&lt;stdin&gt;:207: Creation Set : Success<br>2 subscribes to Set 29<br>&lt;stdin&gt;:9:
 PGRES_FATAL_ERROR select "_mycluster".subscribeSet(29, 1, 2, 't', 'f');&nbsp; - ERROR:&nbsp; deadlock detected<br>DETAIL:&nbsp; Process 25451 waits for ExclusiveLock on relation 4867429 of database 4326133; blocked by process 18388.<br>Process 18388 waits for AccessExclusiveLock on relation 4867482 of database 4326133; blocked by process 25451.<br>HINT:&nbsp; See server log for query details.<br>CONTEXT:&nbsp; SQL statement "LOCK TABLE _mycluster.sl_event IN EXCLUSIVE MODE; INSERT INTO _mycluster.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,<br>ev_data8) VALUES ('1', nextval('_mycluster.sl_event_seq'), now(), "pg_catalog".txid_current_snapshot(), $1, $2, $3, $4, $5, $6, $7, $8, $9); SELECT currval('_mycluster.sl_event_seq');"<br>PL/pgSQL function "subscribeset" line 64 at assignment<br>&lt;stdin&gt;:8: Node 2 subscribes set
 29<br></span></div><div><br><span></span></div><div><span>with autovacuum on the only workaround, I've found is too let Slony do the vacuum by putting autovacuum off on Slony's tables</span></div><div><br><span></span></div><div><span>&nbsp;ALTER TABLE _mycluster.sl_nodelock SET (autovacuum_enabled=off);<br>&nbsp;ALTER TABLE _mycluster.sl_setsync SET (autovacuum_enabled=off);<br>&nbsp;ALTER TABLE _mycluster.sl_table SET (autovacuum_enabled=off);<br>&nbsp;ALTER TABLE _mycluster.sl_sequence SET (autovacuum_enabled=off);<br>&nbsp;ALTER TABLE _mycluster.sl_node SET (autovacuum_enabled=off);<br>&nbsp;ALTER TABLE _mycluster.sl_listen SET (autovacuum_enabled=off);<br>&nbsp;ALTER TABLE _mycluster.sl_path SET (autovacuum_enabled=off);<br>&nbsp;ALTER TABLE _mycluster.sl_subscribe SET (autovacuum_enabled=off);<br>&nbsp;ALTER TABLE _mycluster.sl_set SET (autovacuum_enabled=off);<br>&nbsp;ALTER TABLE _mycluster.sl_event SET (autovacuum_enabled=off);<br>&nbsp;ALTER
 TABLE _mycluster.sl_confirm SET (autovacuum_enabled=off);<br>&nbsp;ALTER TABLE _mycluster.sl_seqlog SET (autovacuum_enabled=off);<br>&nbsp;ALTER TABLE _mycluster.sl_registry SET (autovacuum_enabled=off);<br>&nbsp;ALTER TABLE _mycluster.sl_seqlastvalue SET (autovacuum_enabled=off);<br>&nbsp;ALTER TABLE _mycluster.sl_config_lock SET (autovacuum_enabled=off);<br>&nbsp;ALTER TABLE _mycluster.sl_archive_counter SET (autovacuum_enabled=off);<br>&nbsp;ALTER TABLE _mycluster.sl_status SET (autovacuum_enabled=off);<br>&nbsp;ALTER TABLE _mycluster.sl_log_1 SET (autovacuum_enabled=off);<br>&nbsp;ALTER TABLE _mycluster.sl_log_2 SET (autovacuum_enabled=off);<br></span></div><div><br><span></span></div><div><span>It works with PostgreSQL 8.4.</span></div><div><br><span></span></div><div><span>So I asked myself it is not related to bug 218</span></div><div><br><span></span></div><div><span>David</span><span class="tab"><br></span></div><div><br></div><div
 style="font-family: times new roman, new york, times, serif; font-size: 12pt;"><div style="font-family: times new roman, new york, times, serif; font-size: 12pt;"><font size="2" face="Arial"><hr size="1"><b><span style="font-weight:bold;">De&nbsp;:</span></b> Steven Singer &lt;sjsinger@sympatico.ca&gt;<br><b><span style="font-weight: bold;">À&nbsp;:</span></b> David TECHER &lt;davidtecher@yahoo.fr&gt;<br><b><span style="font-weight: bold;">Cc&nbsp;:</span></b> Slony Hackers &lt;slony1-hackers@lists.slony.info&gt;<br><b><span style="font-weight: bold;">Envoyé le :</span></b> Vendredi 23 Septembre 2011 0h42<br><b><span style="font-weight: bold;">Objet&nbsp;:</span></b> Re: [Slony1-hackers] Request: backporting fix done for bug 218 to REL 2.0 STABLE<br></font><br>On Thu, 22 Sep 2011, David TECHER wrote:<br><br>&gt; Hi<br>&gt; <br>&gt; I asked myself if it could be possible to backport the fix done for bug 218<br>&gt; to&nbsp; tag 2.0 STABLE.<br><br>&gt;
 <br>&gt; I've got several schemas so a lot of tables/sequences to replicate.<br><br>Exactly what problem are you having with 2.0.x that makes you think the changes for bug 218 (<a href="http://www.slony.info/bugzilla/show_bug.cgi?id=218" target="_blank">http://www.slony.info/bugzilla/show_bug.cgi?id=218</a>) will fix your problem?&nbsp; The comments on the bug make me think that bug 218 was caused/exposed by other changes to 2.1.&nbsp;  A lot of the 'locking' changes in 2.1.0 are somewhat related (changing the table we lock, changing where we take the lock etc...), even that bug had multile commits before all the issues were worked out and I would hesitate to start porting those to 2.0.x piecemeal (particularly since 2.1.0 is so close to being out)<br><br><br><br><br><br><br>&gt; <br>&gt; Thanks<br>&gt; <br>&gt; Kind regards<br>&gt; <br>&gt; <br><br><br></div></div></div></body></html>