Hi,

I'm a new Slony user - great to see a clear, active direction for Pg
replication, incidentally - and I have some questions about the IDs 
referenced in "SET ADD TABLE", "LOCK SET" and deadlocks.

I'm working on deploying my application in a "warm standby" replicated
environment using Slony.  I'm aware of the limitations referred to in
the documentation and am prepared to script the hearbeat and failover
triggering myself.

For background, my application uses transactions, "SELECT FOR UPDATE"
and, in one place, "LOCK TABLE" on a single table in "SHARE ROW
EXCLUSIVE MODE".

On to the part I could use some guidance/advice on:

"SET ADD TABLE" says about its ID value: "The numeric value of this ID
also determines the order in which the tables are locked in a LOCK SET
command for example.  So these numbers should represent any applicable
table hierarchy to make sure the slonik command scripts do not deadlock
at any critical moment."

Can you tell me more about what events may trigger a "LOCK SET" command? 
Is this something that happens during the operation of normal
replication, or only when I trigger particular events such as adding a
node, moving a set between nodes, etc.?

What sort of table lock does "LOCK SET" acquire?

Am I correct in understanding "represent any applicable table hierarchy"
to mean the order in which I update (and read???) tables during
transactions?  Are read operations relevant?

Looking at my code I don't always touch tables in the same order, which
I know should be corrected to avoid deadlocks, irregardless of Slony. 
Will replication exacerbate the deadlock problem here - should fix this
before using Slony?  Or if my application is running basically okay
despite my sloppy ordering of operations within tranactions, I shouldn't
worry about adding Slony to the mix?

Thanks for any help or advice!

-- 
_ivan
Open-source billing, ticketing and provisioning
for ISPs, VoIP providers and online businesses
http://www.sisd.com/freeside/