On 02/12/2014 09:51 AM, David Fetter wrote: > On Wed, Feb 12, 2014 at 07:17:51AM -0500, Steve Singer wrote: >> On Tue, 11 Feb 2014, David Fetter wrote: >> >>> On Tue, Feb 11, 2014 at 08:46:26PM -0500, Vick Khera wrote: >>>> On Sat, Feb 8, 2014 at 12:23 PM, Steve Singer <[email protected]> >>>> wrote: >>>> >>>>> Just add the triggers to your tables as you normally would on all >>>>> nodes. >>>> >>>> Which is to say using slonik to run the SQL script that will add >>>> them. >>> >>> Thanks for clarifying that. It's kinda important :) >> >> You can add the triggers via slonik EXECUTE SCRIPT, but in most >> cases you can also add the triggers to all nodes directly with psql. > > In what cases can't I do this? Given our volume, I'm not a huge fan > of the size of the lock EXECUTE SCRIPT might take. >
I don't think modern execute script (ie in 2.1 or 2.2) takes out much locking other than what your DDL is already doing. (I think adding the trigger to a table requires a heavy lock on that table anyway) If the trigger is configured to run on a replica then you can't do it with psql on a live system becaues the trigger might get added (and run) at a different point in the replication stream on different replicas vs the origin (unless your doing something to prevent this, like stopping inserts on your table by shutting down stuff) In cases where the trigger is disabled on the replica then the only time I think not using execute script would be a problem is when you have other DDL changes pending via execute script Ie if you create the table via EXECUTE SCRIPT, but then use psql to add the the trigger to the table on a replica BEFORE the execute script that adds the table runs on that replica you will have a problem. >> With the psql method the triggers get added to all nodes immedately, >> even if the node is behind in replication. With a origin only >> trigger this shouldn't make a difference. If the trigger does stuff >> on replicas then this is more of an issue. > > The trigger only does stuff on a replica if that replica takes over as > origin. > > Cheers, > David. > _______________________________________________ Slony1-general mailing list [email protected] http://lists.slony.info/mailman/listinfo/slony1-general
