NAME¶
STORE LISTEN - Configure Slony-I node to indicate where to listen for events
SYNOPSIS¶
STORE LISTEN (options);
DESCRIPTION¶
A ‘listen’ entry causes a node (receiver) to query an event
provider for events that originate from a specific node, as well as
confirmations from every existing node. It requires a ‘path’ to
exist so that the receiver (as client) can connect to the provider (as
server).
Every node in the system must listen for events from every other node in the
system. As a general rule of thumb, a subscriber (see
SLONIK SUBSCRIBE
SET(7)) should listen for events of the set's origin on the same provider,
where it receives the data from. In turn, the origin of the data set should
listen for events from the origin in the opposite direction. A node can listen
for events from one and the same origin on different providers at the same
time. However, to process
SYNC events from that origin, all data
providers must have the same or higher sync status, so this will not result in
any faster replication behaviour.
- ORIGIN = ival
- Node ID of the event origin the receiver is listening for.
- PROVIDER = ival
- Node ID of the node from which the receiver gets events that come from the
origin. If not specified, default is the origin.
- RECEIVER = ival
- The ID of the node receiving the events.
This uses “schemadocstorelisten(p_receiver integer, p_provider integer,
p_origin integer)” [not available as a man page].
For more details, see “Slony-I Listen Paths” [not available as a
man page].
EXAMPLE¶
STORE LISTEN ( ORIGIN = 1, RECEIVER = 2, PROVIDER = 3 );
LOCKING BEHAVIOUR ¶
No application-visible locking should take place.
SLONIK EVENT CONFIRMATION BEHAVIOUR ¶
Slonik waits for the command submitted to the previous event node to be
confirmed on the specified event node before submitting this command.
This command was introduced in Slony-I 1.0. As of version 1.1, you
should
no longer need to use this command, as listen paths are generated
automatically.