Skip site navigation (1) Skip section navigation (2)

Re: pgsql doesn't include replication...

From: Christopher Browne <cbbrowne(at)acm(dot)org>
To: pgsql-advocacy(at)postgresql(dot)org
Subject: Re: pgsql doesn't include replication...
Date: 2005-02-12 23:22:14
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-advocacy
josh(at)agliodbs(dot)com (Josh Berkus) wrote:
> KL-
>> Hmm, the Slony guys talked to us (the phpPgAdmin team) about doing this as
>> well - but they never got back to us with any implementation details :D
>> Perhaps I'll have to look at this new functionailty in pgAdmin and imitate
>> it?  I don't really want to spend forever learning Slony to implement the
>> interface :D
> Well, the slony commands are pretty well-documented.  And you can always pop 
> back on IRC.

The documentation tree includes docs about the stored functions, which
are probably the way to do this.

The problem of course is that everyone's pretty busy.  Jan is
evidently pretty much hiding after he got back from France, and I have
had no lack of things to do.

There's some useful "protocol" to consider when looking at those
stored functions, as there are generally two for each action:

 1.  A "main" one, which gets invoked on one node

   e.g. - to add a path between nodes, you call
      storepath( integer, integer, text, integer )

     These sometimes can be called "anywhere," but often need to be
     called on the node where some interesting action is supposed to
     take place.  That way, the procedure can successfully check the
     state of that node and give a decent error message if it fails.

     If the action looks like it'll succeed, Slony-I "raises an event"
     to broadcast the activity to everywhere else.

 2.  Then, there's an "internal" one that does internal work that
     should be done on each node.

      storepath_int ( integer, integer, text, integer )

     When the 'STORE_PATH' event gets broadcasted everywhere, this
     "internal" function is used to make the event take effect

Thus, it's important to run the right functions, and sometimes to run
them on the right node.  With storepath(), where to run it isn't
important, as it'll broadcast paths onwards as it propagates.  But
with subscribeset(), it had better initially run on the node that's
supposed to be doing the subscribing.

That's reasonably well documented in the functions themselves, so that
trial and error will get you somewhere...
(format nil "~S(at)~S" "cbbrowne" "")
Blood is thicker than water, and much tastier. 

In response to

pgsql-advocacy by date

Next:From: Christopher BrowneDate: 2005-02-12 23:26:53
Subject: Re: pgsql doesn't include replication...
Previous:From: Josh BerkusDate: 2005-02-12 20:49:46
Subject: Re: pgsql doesn't include replication...

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group