Christopher B. Browne's Home Page
cbbrowne@acm.org

7.8. Not Using Slonik - Bare Metal Slony-I Functions

There are cases where it may make sense to directly use the stored functions that implement the various pieces of Slony-I. Slonik doesn't do terribly much "magic;" it is common for Slonik commands to simply involve deciding on a node at which to apply a command, and then submit a SQL query consisting of a call to one of the Slony-I stored functions.

The developers of Slony-I anticipate that interested parties may wish to develop graphical tools as an alternative to Slonik; it would be entirely appropriate in such cases to submit configuration requests directly via the stored functions. If you plan to do so, it is suggested that you examine how the stored procedures are used in slonik.c, as that represents the most correct use of the functions.

When debugging problems in "troubled" Slony-I clusters, it has also occasionally proven useful to use the stored functions. This has been particularly useful for cases where sl_listen configuration has been broken, and events have not been propagating properly. The "easiest" fix was to:

select _slonycluster.droplisten(li_origin,li_provider,li_receiver) from _slonycluster.sl_listen;

select _slonycluster.storelisten(pa_server, pa_server, pa_client) from _slonycluster.sl_path;

The result of this set of queries is to regenerate and propagate the listen paths. By running the main _slonycluster.storelisten() function, STORE_LISTEN events are raised to cause the listen paths to propagate to the other nodes in the cluster.

If there was a local problem on one node, and you didn't want the updates to propagate (this would be an unusual situation; you almost certainly want to fix things everywhere), the queries would instead be:

select slonycluster.droplisten_int(li_origin,li_provider,li_receiver) from _slonycluster.sl_listen;

select _slonycluster.storelisten_int(pa_server, pa_server, pa_client) from _slonycluster.sl_path;

If you are planning to add Slony-I support to other tools (e.g. - adding replication support to something like pgAdmin III ), you need to be clear on where various functions need to be called. The normal "protocol" is thus:

Google
Contact me at cbbrowne@acm.org