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: m3mzu9qs7t.fsf@knuth.knuth.cbbrowne.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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
"everywhere."

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" "gmail.com")
http://linuxdatabases.info/~cbbrowne/slony.html
Blood is thicker than water, and much tastier.

In response to

Browse pgsql-advocacy by date

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