Christopher Browne cbbrowne
Mon Oct 18 21:28:59 PDT 2004
We have noticed a need to run some things in a node-dependent manner,
that is, where there are processes (triggers, to be exact) that need
to run on some nodes, and not on other nodes.

In looking at solutions, I'm seeing that this is not something that is
unique to just one trigger, and it looks, therefore, as though this is
something that may be of wider interest.  There's little sense in
hacking something up for our internal purposes if it can be added in
for everyone else to use (and debug! :^)).

The thought:

 - Create a new table that is replicated everywhere 

   (Initial assumption: Use Slony-I to replicate it; if this
   ultimately integrates into Slony-I, then presumably it would be
   handled inside Slony-I...)

   create table public.sl_run_on_node (
     service character varying(16),
     sl_node integer,
     primary key(service, sl_node)
   );

 - Create a 'control function.'

   create or replace function public.run_service_here (character varying(16))
   returns boolean as
   'select exists (select * from public.sl_run_on_node 
                   where service = $1
                   and sl_node = @NAMESPACE at .getLocalNodeId(''@NAMESPACE@));'
   language sql;

If we want a trigger that we identify as 'FOO_ON_SLAVES' to run on
nodes 2, 4, and 6, then we'd add in the rules:

insert into sl_run_on_node (service, sl_node) values ('FOO_ON_SLAVES', 2);
insert into sl_run_on_node (service, sl_node) values ('FOO_ON_SLAVES', 4);
insert into sl_run_on_node (service, sl_node) values ('FOO_ON_SLAVES', 6);

The trigger would invoke a stored function, which would have to add
in, near the beginning, the code:

   if not run_service_here('FOO_ON_SLAVES') then
      return NEW;
   end if;

Some questions that fall from this:

 - Does this sound like it would be generally useful?

 - Are there some manifest failings that should be fixed up?

 - How would it make sense to integrate this into Slony-I?

   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.
-- 
"cbbrowne","@","ca.afilias.info"
<http://dev6.int.libertyrms.com/>
Christopher Browne
(416) 673-4124 (land)


More information about the Slony1-general mailing list