On Wed, Nov 21, 2012 at 04:57:32PM +0200, Achilleas Mantzios wrote:
...
> session_replication_role related and I have the idea that maybe those 
> features were introduced specifically for Slony

Yes, they were.

> Solution 1)
> explicitly disabling the triggers at the start of the 
> transaction and re-enabling them, but that would require 
> knowledge of the name of table in question prior to execution 
> of the replication command

It also does heavy locking, and does not turn off rules, so 
using session_replication_role (SRR) is much better.

> Solution 2)
> the ENABLE REPLICA TRIGGER in combination with session_replication_role.
> Setting default ALTER DATABASE dbname SET session_replication_role TO REPLICA

Not good. Pretty dangerous unless you are 100% sure that every application 
logging into the database is aware of that setting. That's backwards of the 
optimal solution:

> Solution 3)
> make the code updating those multi-master tables, replication-aware by putting 
> SET local session_replication_role TO REPLICA; inside the affecting transactions. 
> But this also has the obvious disadvantage of making application and 
> system logic blend together, and also making the app programmer prone to errors.

Well, this is exactly the use case that session_replication_role was 
designed for, so I would prefer to see stronger reasons for 
rejecting it.

/twocents


-- 
Greg Sabino Mullane greg at endpoint.com
End Point Corporation
PGP Key: 0x14964AC8
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
Url : http://lists.slony.info/pipermail/slony1-general/attachments/20121121/cd779a7c/attachment.pgp