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 [email protected] End Point Corporation PGP Key: 0x14964AC8
pgpJpAL5qABgB.pgp
Description: PGP signature
_______________________________________________ Slony1-general mailing list [email protected] http://lists.slony.info/mailman/listinfo/slony1-general
