Mon Oct 18 22:21:48 PDT 2004
- Previous message: [Slony1-general] RFC: Running things in a "node-dependent" manner
- Next message: [Slony1-general] RFC: Running things in a "node-dependent" manner
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
> > Some questions that fall from this: > > - Does this sound like it would be generally useful? Yes. Actually I thougth that this *is* how STORE TRIGGER worked ;) OTOH I can probably do "STORE TRIGGER (TRIGGER NAME ='runs_on_slaves')" and then make the same trigger do different things on different slaves ;) > - Are there some manifest failings that should be fixed up? Not an failing, but one should think through how this will play together with switchover/failover. > - How would it make sense to integrate this into Slony-I? Yes. One on my uses of slony is replicating different sets of tables to multiple computers for OLAP processing and some of initial post-processing here is best done using triggers. and these triggers do different things on different computers. I guess an extra parameter NODE to STORE TRIGGER which manipulates and extra field in table sl_trigger (called sl_node ;) The default could be still NODE = ALL, which adds the trigger for all nodes. > For instance, if more tightly integrated with Slony-I, this table > wouldn't be replicated, but would instead be updated via raising > Slony EVENTs. And we'd need Slonik syntax for it. and if integrated, the initial if not run_service_here('FOO_ON_SLAVES') then return NEW; end if; is not needed as it is handled by slony. but you probably already thought about that ;) --------------- Hannu
- Previous message: [Slony1-general] RFC: Running things in a "node-dependent" manner
- Next message: [Slony1-general] RFC: Running things in a "node-dependent" manner
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Slony1-general mailing list