Slony-I 1.2.12
Postgres 8.2.1
2 Nodes: 1 origin, 1 subscriber, 1 replication set

This discussion is regarding locking--a popular and sometimes confusing
topic for a lot of us I know. I've read the documentation several times now
and searched the mailing list (via Nabble.com) for related locking issues.

I continue to see posts that mention spreading tables across multiple
replication sets in order to reduce locking issues. The documentation has
more than one place that suggests this is a good strategy. However, on this
page (http://slony.info/documentation/ddlchanges.html), there is this
important note:

--- BEGIN QUOTE ----------------------------------------------
You may be able to define replication sets that consist of smaller sets of
tables so that fewer locks need to be taken in order for the DDL script to
make it into place.

If a particular DDL script only affects one table, it should be unnecessary
to lock all application tables.

Note: Actually, as of version 1.1.5 and later, this is NOT TRUE. The danger
of someone making DDL changes that crosses replication sets seems
sufficiently palpable that slon has been changed to lock ALL replicated
tables, whether they are in the specified replication set or not.
--- END QUOTE ----------------------------------------------

Therefore, running execute_script will LOCK ALL TABLES IN ALL REPLICATION
SETS regardless. Correct?

Now onto my issue at hand: Twice now, we've seen a pattern that looks like
Slony is waiting on a large index creation to complete, and then an
application gets stuck waiting behind Slony's locks. Here is why this is
such a mystery to me. The index is being created by a non-Slony process on a
table that is not in any replication set and that has no foreign key
relationships to any other table. It makes no sense to me that Slony would
be waiting on this index to finish.

On top of that, the application commit that is waiting is simply trying to
insert rows into a table that is again not contained in any replication set
nor does it have any foreign key relationships to any other table.

On top of THAT, why would Slony need to lock anything outside of it's own
_slony schema objects when simply logging SYNC events? From everything I can
tell, Slony had nothing to actually replicate during this time--no need to
require any locks on any of my tables whether in replication sets or not.

At this point in time, I'm not 100% sure the application commit was blocked
by Slony except we never had this problem before Slony.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.slony.info/pipermail/slony1-general/attachments/20080222/=
67507079/attachment.htm