SYNOPSIS

STORE PATH (options); \kx

DESCRIPTION

Configures how the replication daemon of one node connects to the database of another node. If the replication system is supposed to use a special backbone network segment, this is the place to user the special IP addresses or hostnames. An existing configuration can be overwritten.

The conninfo string must contain all information to connect to the database as the replication superuser. The names \(oqserver\(cq or \(oqclient\(cq have nothing to do with the particular role of a node within the cluster configuration. It should be simply viewed as \(oqthe server\(cq has the message or data that \(oqthe client is supposed to get.\(cq For a simple 2 node setup, paths into both directions must be configured.

It does not do any harm to configure path information from every node to every other node (full cross product). The connections are not established unless they are required to actually transfer events or confirmations because of listen entries or data because of subscriptions.

\*(T<SERVER = ival \*(T>

Node ID of the database to connect to.

\*(T<CLIENT = ival \*(T>

Node ID of the replication daemon connecting.

\*(T<CONNINFO = string \*(T>

\*(T<PQconnectdb()\*(T> argument to establish the connection.

\*(T<CONNRETRY = ival \*(T>

Number of seconds to wait before another attempt to connect is made in case the server is unavailable. Default is 10.

This uses “schemadocstorepath(p_pa_connretry integer, p_pa_conninfo integer, p_pa_client text, p_pa_server integer)” [not available as a man page].

EXAMPLE

\*(T<STORE PATH ( SERVER = 1, CLIENT = 2,
             CONNINFO = 'dbname=testdb host=server1 user=slony'
           );
    \*(T>

LOCKING BEHAVIOUR

No application-visible locking should take place.

SLONIK EVENT CONFIRMATION BEHAVIOUR

Slonik does not wait for event confirmations before performing this command

VERSION INFORMATION

This command was introduced in Slony-I 1.0