Slony1 PostgreSQL Replication - Could slony replicate tables with OID?

Author

Could slony replicate tables with OID?

µ¥³Ï

2005-07-11, 8:24 pm

Hello, all!
I want to know that if slony can replicate tables with oid for this feature is very important for me. To test this idea, I made some changes to the "Replicating Your First Database" chapt of the "Slony-I Administration" documentation. It turns out that oids in the table of master database are different to those of slave database.
Is there any mistake? Please help me, Any effort will be appreciated. Thanks very much!

The following is the modified document. I have marked the newly added contents red color.

--------------------------------------------------------------------------

Slony-I REL_1_1_0 Documentation
Prev Fast Forward Next

--------------------------------------------------------------------------------

Slony-I Administration
The Slony Global Development Group
Christopher Browne

--------------------------------------------------------------------------------

1. Replicating Your First Database
In this example, we will be replicating a brand new pgbench database. The mechanics of replicating an existing database are covered here, however we recommend that you learn how Slony-I functions by using a fresh new non-production database.

The Slony-I replication engine is trigger-based, allowing us to replicate databases (or portions thereof) running under the same postmaster.

This example will show how to replicate the pgbench database running on localhost (master) to the pgbench slave database also running on localhost (slave). We make a couple of assumptions about your PostgreSQL configuration:

a.. You have tcpip_socket=true in your postgresql.conf and

b.. You have enabled access in your cluster(s) via pg_hba.conf

The REPLICATIONUSER needs to be a PostgreSQL superuser. This is typically postgres or pgsql, although in complex environments it is quite likely a good idea to define a slony user to distinguish between the roles.

You should also set the following shell variables:

a.. CLUSTERNAME=slony_ex
ample

b.. MASTERDBNAME=pgbench

c.. SLAVEDBNAME=pgbenchs
lave

d.. MASTERHOST=localhost

e.. SLAVEHOST=localhost

f.. REPLICATIONUSER=pgsq
l

g.. PGBENCHUSER=pgbench

Here are a couple of examples for setting variables in common shells:

a.. bash, sh, ksh export CLUSTERNAME=slony_ex
ample

b.. (t)csh: setenv CLUSTERNAME slony_example

Warning
If you're changing these variables to use different hosts for MASTERHOST and SLAVEHOST, be sure not to use localhost for either of them. This will result in an error similar to the following:

ERROR remoteListenThread_1
: db_getLocalNodeId() returned 2 - wrong database?

1.1. Creating the pgbenchuser
createuser -A -D $PGBENCHUSER

1.2. Preparing the databases
createdb -O $PGBENCHUSER -h $MASTERHOST $MASTERDBNAME
createdb -O $PGBENCHUSER -h $SLAVEHOST $SLAVEDBNAME
pgbench -i -s 1 -U $PGBENCHUSER -h $MASTERHOST $MASTERDBNAMEpsql -U $REPLICATIONUSER -h $MASTERHOST $MASTERDBNAME pgbench=# CREATE TABLE object(name varchar, PRIMARY KEY(oid)); INSERT INTO object VALUES('aaa');Becaus
e Slony-I depends on the databases having the pl/pgSQL procedural language installed, we better install it now. It is possible that you have installed pl/pgSQL into the template1 database in which case you can skip this step because it's already installed into the $MASTERDBNAME.

createlang -h $MASTERHOST plpgsql $MASTERDBNAME
Slony-I does not automatically copy table definitions from a master when a slave subscribes to it, so we need to import this data. We do this with pg_dump.

pg_dump -s -U $REPLICATIONUSER -h $MASTERHOST $MASTERDBNAME | psql -U $REPLICATIONUSER -h $SLAVEHOST $SLAVEDBNAME
To illustrate how Slony-I allows for on the fly replication subscription, let's start up pgbench. If you run the pgbench application in the foreground of a separate terminal window, you can stop and restart it with different parameters at any time. You'll need to re-export the variables again so they are available in this session as well.

The typical command to run pgbench would look like:

pgbench -s 1 -c 5 -t 1000 -U $PGBENCHUSER -h $MASTERHOST $MASTERDBNAME
This will run pgbench with 5 concurrent clients each processing 1000 transactions against the pgbench database running on localhost as the pgbench user.

1.3. Configuring the Database for Replication.
Creating the configuration tables, stored procedures, triggers and configuration is all done through the slonik tool. It is a specialized scripting aid that mostly calls stored procedures in the master/slave (node) databases. The script to create the initial configuration for the simple master-slave setup of our pgbench database looks like this:

#!/bin/sh

slonik <<_EOF_
#--
# define the namespace the replication system uses in our example it is
# slony_example
#--
cluster name = $CLUSTERNAME;

#--
# admin conninfo's are used by slonik to connect to the nodes one for each
# node on each side of the cluster, the syntax is that of PQconnectdb in
# the C-API
# --
node 1 admin conninfo = 'dbname=$MASTERDBNAM
E host=$MASTERHOST user=$REPLICATIONUSE
R';
node 2 admin conninfo = 'dbname=$SLAVEDBNAME
host=$SLAVEHOST user=$REPLICATIONUSE
R';

#--
# init the first node. Its id MUST be 1. This creates the schema
# _$CLUSTERNAME containing all replication system specific database
# objects.

#--
init cluster ( id=1, comment = 'Master Node');

#--
# Because the history table does not have a primary key or other unique
# constraint that could be used to identify a row, we need to add one.
# The following command adds a bigint column named
# _Slony- I_$CLUSTERNAME_rowID
to the table. It will have a default value
# of nextval('_$CLUSTERNA
ME.s1_rowid_seq'), and have UNIQUE and NOT NULL
# constraints applied. All existing rows will be initialized with a
# number
#--
table add key (node id = 1, fully qualified name = 'public.history');

#--
# Slony-I organizes tables into sets. The smallest unit a node can
# subscribe is a set. The following commands create one set containing
# all 4 pgbench tables. The master or origin of the set is node 1.
#--
create set (id=1, origin=1, comment='All pgbench tables');
set add table (set id=1, origin=1, id=1, fully qualified name = 'public.accounts', comment='accounts table');
set add table (set id=1, origin=1, id=2, fully qualified name = 'public.branches', comment='branches table');
set add table (set id=1, origin=1, id=3, fully qualified name = 'public.tellers', comment='tellers table');
set add table (set id=1, origin=1, id=4, fully qualified name = 'public.history', comment='history table', key = serial); set add table (set id=1, origin=1, id=5, fully qualified name = 'public.object', comment='table with oid');

#--
# Create the second node (the slave) tell the 2 nodes how to connect to
# each other and how they should listen for events.
#--

store node (id=2, comment = 'Slave node');
store path (server = 1, client = 2, conninfo='dbname=$MA
STERDBNAME host=$MASTERHOST user=$REPLICATIONUSE
R');
store path (server = 2, client = 1, conninfo='dbname=$SL
AVEDBNAME host=$SLAVEHOST user=$REPLICATIONUSE
R');
store listen (origin=1, provider = 1, receiver =2);
store listen (origin=2, provider = 2, receiver =1);
_EOF_
Is the pgbench still running? If not start it again.

At this point we have 2 databases that are fully prepared. One is the master database in which pgbench is busy accessing and changing rows. It's now time to start the replication daemons.

On $MASTERHOST the command to start the replication engine is

slon $CLUSTERNAME " dbname=$MASTERDBNAME
user=$REPLICATIONUSE
R host=$MASTERHOST"
Likewise we start the replication system on node 2 (the slave)

slon $CLUSTERNAME "dbname=$SLAVEDBNAME user=$REPLICATIONUSE
R host=$SLAVEHOST"
Even though we have the slon running on both the master and slave, and they are both spitting out diagnostics and other messages, we aren't replicating any data yet. The notices you are seeing is the synchronization of cluster configurations between the 2 slon processes.

To start replicating the 4 pgbench tables (set 1) from the master (node id 1) the the slave (node id 2), execute the following script.

#!/bin/sh
slonik <<_EOF_
# ----
# This defines which namespace the replication system uses
# ----
cluster name = $CLUSTERNAME;

# ----
# Admin conninfo's are used by the slonik program to connect
# to the node databases. So these are the PQconnectdb arguments
# that connect from the administrators workstation (where
# slonik is executed).
# ----
node 1 admin conninfo = 'dbname=$MASTERDBNAM
E host=$MASTERHOST user=$REPLICATIONUSE
R';
node 2 admin conninfo = 'dbname=$SLAVEDBNAME
host=$SLAVEHOST user=$REPLICATIONUSE
R';

# ----
# Node 2 subscribes set 1
# ----
subscribe set ( id = 1, provider = 1, receiver = 2, forward = no);
_EOF_
Any second now, the replication daemon on $SLAVEHOST will start to copy the current content of all 4 replicated tables. While doing so, of course, the pgbench application will continue to modify the database. When the copy process is finished, the replication daemon on $SLAVEHOST will start to catch up by applying the accumulated replication log. It will do this in little steps, 10 seconds worth of application work at a time. Depending on the performance of the two systems involved, the sizing of the two databases, the actual transaction load and how well the two databases are tuned and maintained, this catchup process can be a matter of minutes, hours, or eons.

You have now successfully set up your first basic master/slave replication system, and the 2 databases should, once the slave has caught up, contain identical data. That's the theory, at least. In practice, it's good to build confidence by verifying that the datasets are in fact the same.

The following script will create ordered dumps of the 2 databases and compare them. Make sure that pgbench has completed its testing, and that your slon sessions have caught up.

#!/bin/sh
echo -n "**** comparing sample1 ... "
psql -U $REPLICATIONUSER -h $MASTERHOST $MASTERDBNAME >dump.tmp.1.$$ <<_EOF_
select 'accounts:'::text, aid, bid, abalance, filler
from accounts order by aid;
select 'branches:'::text, bid, bbalance, filler
from branches order by bid;
select 'tellers:'::text, tid, bid, tbalance, filler
from tellers order by tid;
select 'history:'::text, tid, bid, aid, delta, mtime, filler,
"_Slony-I_$& #123;CLUSTERNAME}_ro
wID"
from history order by "_Slony-I_$& #123;CLUSTERNAME}_ro
wID";
_EOF_
psql -U $REPLICATIONUSER -h $SLAVEHOST $SLAVEDBNAME >dump.tmp.2.$$ <<_EOF_
select 'accounts:'::text, aid, bid, abalance, filler
from accounts order by aid;
select 'branches:'::text, bid, bbalance, filler
from branches order by bid;
select 'tellers:'::text, tid, bid, tbalance, filler
from tellers order by tid;
select 'history:'::text, tid, bid, aid, delta, mtime, filler,
"_Slony-I_$& #123;CLUSTERNAME}_ro
wID"
from history order by "_Slony-I_$& #123;CLUSTERNAME}_ro
wID";
_EOF_

if diff dump.tmp.1.$$ dump.tmp.2.$$ >$CLUSTERNAME.diff ; then
echo "success - databases are equal."
rm dump.tmp.?.$$
rm $CLUSTERNAME.diff
else
echo "FAILED - see $CLUSTERNAME.diff for database differences"
fi
Note that there is somewhat more sophisticated documentation of the process in the Slony-I source code tree in a file called slony-I-basic-mstr-slv.txt.

If this script returns FAILED please contact the developers at http://slony.info/

--------------------------------------------------------------------------------
Prev Home Next
Defining Slony-I Replication Sets Slon daemons

Jan Wieck

2005-07-12, 3:24 am

On 7/11/2005 9:46 PM, =E5=8D=95=E8=AF=9A wrote:

> Hello, all!
> I want to know that if slony can replicate tables with oid fo=
r this feature is very important for me. To test this idea, I made some c=
hanges to the "Replicating Your First Database" chapt of the "Slony-I Adm=
inistration" documentation. It turns out that oids in the table of master=
database are different to those of slave database.=20
> Is there any mistake? Please help me, Any effort will be appr=
eciated. Thanks very much!

No mistake at all. The usage of OID's for user tables is depricated,=20
strongly discouraged and OID's are not supported by the Slony-I=20
replication system. There are no plans to add support for OID's. Please=20
convert your application to use another kind of row identification.

Jan

> =20
> The following is the modified document. I have marked the new=
ly added contents red color.=20
>=20
> -----------------------------------------------------------------------=
---
>=20
>=20
> Slony-I REL_1_1_0 Documentation=20
> Prev Fast Forward Next=20
>=20
> -----------------------------------------------------------------------=
---------
>=20
> Slony-I Administration
> The Slony Global Development Group
> Christopher Browne
>=20
> -----------------------------------------------------------------------=
---------
>=20
> 1. Replicating Your First Database
> In this example, we will be replicating a brand new pgbench database. T=
he mechanics of replicating an existing database are covered here, howeve=
r we recommend that you learn how Slony-I functions by using a fresh new =
non-production database.
>=20
> The Slony-I replication engine is trigger-based, allowing us to replica=
te databases (or portions thereof) running under the same postmaster.
>=20
> This example will show how to replicate the pgbench database running on=
localhost (master) to the pgbench slave database also running on localho=
st (slave). We make a couple of assumptions about your PostgreSQL configu=
ration:=20
>=20
>=20
>=20
> a.. You have tcpip_socket=3Dtrue in your postgresql.conf and
>=20
> b.. You have enabled access in your cluster(s) via pg_hba.conf
>=20
>=20
> The REPLICATIONUSER needs to be a PostgreSQL superuser. This is typical=
ly postgres or pgsql, although in complex environments it is quite likely=
a good idea to define a slony user to distinguish between the roles.
>=20
> You should also set the following shell variables:=20
>=20
>=20
>=20
> a.. CLUSTERNAME=3Dslony_
example
>=20
> b.. MASTERDBNAME=3Dpgben
ch
>=20
> c.. SLAVEDBNAME=3Dpgbenc
hslave
>=20
> d.. MASTERHOST=3Dlocalho
st
>=20
> e.. SLAVEHOST=3Dlocalhos
t
>=20
> f.. REPLICATIONUSER=3Dpg
sql
>=20
> g.. PGBENCHUSER=3Dpgbenc
h
>=20
>=20
> Here are a couple of examples for setting variables in common shells:=20
>=20
>=20
>=20
> a.. bash, sh, ksh export CLUSTERNAME=3Dslony_
example
>=20
> b.. (t)csh: setenv CLUSTERNAME slony_example
>=20
>=20
>=20
>=20
> Warning=20
> If you're changing these variables to use different hosts for MAS=
TERHOST and SLAVEHOST, be sure not to use localhost for either of them. T=
his will result in an error similar to the following:
>=20
> ERROR remoteListenThread_1
: db_getLocalNodeId() returned 2 - wron=
g database?
> =20
>=20
>=20
> 1.1. Creating the pgbenchuser
> createuser -A -D $PGBENCHUSER
>=20
> 1.2. Preparing the databases
> createdb -O $PGBENCHUSER -h $MASTERHOST $MASTERDBNAME
> createdb -O $PGBENCHUSER -h $SLAVEHOST $SLAVEDBNAME
> pgbench -i -s 1 -U $PGBENCHUSER -h $MASTERHOST $MASTERDBNAMEpsql -U $RE=
PLICATIONUSER -h $MASTERHOST $MASTERDBNAME pgbench=3D# CREATE TABLE objec=
t(name varchar, PRIMARY KEY(oid)); INSERT INTO object VALUES('aaa');Becau=

se Slony-I depends on the databases having the pl/pgSQL procedural langua=
ge installed, we better install it now. It is possible that you have inst=
alled pl/pgSQL into the template1 database in which case you can skip thi=
s step because it's already installed into the $MASTERDBNAME.=20
>=20
> createlang -h $MASTERHOST plpgsql $MASTERDBNAME
> Slony-I does not automatically copy table definitions from a master whe=
n a slave subscribes to it, so we need to import this data. We do this wi=
th pg_dump.=20
>=20
> pg_dump -s -U $REPLICATIONUSER -h $MASTERHOST $MASTERDBNAME | psql -U $=
REPLICATIONUSER -h $SLAVEHOST $SLAVEDBNAME
> To illustrate how Slony-I allows for on the fly replication subscriptio=
n, let's start up pgbench. If you run the pgbench application in the fore=
ground of a separate terminal window, you can stop and restart it with di=
fferent parameters at any time. You'll need to re-export the variables ag=
ain so they are available in this session as well.
>=20
> The typical command to run pgbench would look like:=20
>=20
> pgbench -s 1 -c 5 -t 1000 -U $PGBENCHUSER -h $MASTERHOST $MASTERDBNAME
> This will run pgbench with 5 concurrent clients each processing 1000 tr=
ansactions against the pgbench database running on localhost as the pgben=
ch user.
>=20
> 1.3. Configuring the Database for Replication.
> Creating the configuration tables, stored procedures, triggers and conf=
iguration is all done through the slonik tool. It is a specialized script=
ing aid that mostly calls stored procedures in the master/slave (node) da=
tabases. The script to create the initial configuration for the simple ma=
ster-slave setup of our pgbench database looks like this:=20
>=20
> #!/bin/sh
>=20
> slonik <<_EOF_
> #--
> # define the namespace the replication system uses in our example it i=
s
> # slony_example
> #--
> cluster name =3D $CLUSTERNAME;
>=20
> #--
> # admin conninfo's are used by slonik to connect to the nodes one for =
each
> # node on each side of the cluster, the syntax is that of PQconnectdb =
in
> # the C-API
> # --
> node 1 admin conninfo =3D 'dbname=3D$MASTERDBN
AME host=3D$MASTERHOST u=
ser=3D$REPLICATIONUS
ER';
> node 2 admin conninfo =3D 'dbname=3D$SLAVEDBNA
ME host=3D$SLAVEHOST use=
r=3D$REPLICATIONUSER
';
>=20
> #--
> # init the first node. Its id MUST be 1. This creates the schema
> # _$CLUSTERNAME containing all replication system specific database
> # objects.
>=20
> #--
> init cluster ( id=3D1, comment =3D 'Master Node');
> =20
> #--
> # Because the history table does not have a primary key or other uniqu=
e
> # constraint that could be used to identify a row, we need to add one.
> # The following command adds a bigint column named
> # _Slony- I_$CLUSTERNAME_rowID
to the table. It will have a default va=
lue
> # of nextval('_$CLUSTERNA
ME.s1_rowid_seq'), and have UNIQUE and NOT NU=
LL
> # constraints applied. All existing rows will be initialized with a
> # number
> #--
> table add key (node id =3D 1, fully qualified name =3D 'public.history=
');
>=20
> #--
> # Slony-I organizes tables into sets. The smallest unit a node can
> # subscribe is a set. The following commands create one set containin=
g
> # all 4 pgbench tables. The master or origin of the set is node 1.
> #--
> create set (id=3D1, origin=3D1, comment=3D'All pgbench tables');
> set add table (set id=3D1, origin=3D1, id=3D1, fully qualified name =3D=
'public.accounts', comment=3D'accounts table');
> set add table (set id=3D1, origin=3D1, id=3D2, fully qualified name =3D=
'public.branches', comment=3D'branches table');
> set add table (set id=3D1, origin=3D1, id=3D3, fully qualified name =3D=
'public.tellers', comment=3D'tellers table');
> set add table (set id=3D1, origin=3D1, id=3D4, fully qualified name =3D=
'public.history', comment=3D'history table', key =3D serial); =
set add table (set id=3D1, origin=3D1, id=3D5, fully qualified name =3D =
'public.object', comment=3D'table with oid');
>=20
> #--
> # Create the second node (the slave) tell the 2 nodes how to connect t=
o
> # each other and how they should listen for events.
> #--
>=20
> store node (id=3D2, comment =3D 'Slave node');
> store path (server =3D 1, client =3D 2, conninfo=3D'dbname=3
D$MASTERDB=
NAME host=3D$MASTERHOST user=3D$REPLICATIONU
SER');
> store path (server =3D 2, client =3D 1, conninfo=3D'dbname=3
D$SLAVEDBN=
AME host=3D$SLAVEHOST user=3D$REPLICATIONU
SER');
> store listen (origin=3D1, provider =3D 1, receiver =3D2);
> store listen (origin=3D2, provider =3D 2, receiver =3D1);
> _EOF_
> Is the pgbench still running? If not start it again.
>=20
> At this point we have 2 databases that are fully prepared. One is the m=
aster database in which pgbench is busy accessing and changing rows. It's=
now time to start the replication daemons.
>=20
> On $MASTERHOST the command to start the replication engine is=20
>=20
> slon $CLUSTERNAME " dbname=3D$MASTERDBNA
ME user=3D$REPLICATIONU
SER host=3D=
$MASTERHOST"
> Likewise we start the replication system on node 2 (the slave)=20
>=20
> slon $CLUSTERNAME " dbname=3D$SLAVEDBNAM
E user=3D$REPLICATIONU
SER host=3D=
$SLAVEHOST"
> Even though we have the slon running on both the master and slave, and =
they are both spitting out diagnostics and other messages, we aren't repl=
icating any data yet. The notices you are seeing is the synchronization o=
f cluster configurations between the 2 slon processes.
>=20
> To start replicating the 4 pgbench tables (set 1) from the master (node=
id 1) the the slave (node id 2), execute the following script.=20
>=20
> #!/bin/sh
> slonik <<_EOF_
> # ----
> # This defines which namespace the replication system uses
> # ----
> cluster name =3D $CLUSTERNAME;
>=20
> # ----
> # Admin conninfo's are used by the slonik program to connect
> # to the node databases. So these are the PQconnectdb arguments
> # that connect from the administrators workstation (where
> # slonik is executed).
> # ----
> node 1 admin conninfo =3D 'dbname=3D$MASTERDBN
AME host=3D$MASTERHOST =
user=3D$REPLICATIONU
SER';

> node 2 admin conninfo =3D 'dbname=3D$SLAVEDBNA
ME host=3D$SLAVEHOST us=
er=3D$REPLICATIONUSE
R';
>=20
> # ----
> # Node 2 subscribes set 1
> # ----
> subscribe set ( id =3D 1, provider =3D 1, receiver =3D 2, forward =3D=
no);
> _EOF_
> Any second now, the replication daemon on $SLAVEHOST will start to copy=
the current content of all 4 replicated tables. While doing so, of cours=
e, the pgbench application will continue to modify the database. When the=
copy process is finished, the replication daemon on $SLAVEHOST will star=
t to catch up by applying the accumulated replication log. It will do thi=
s in little steps, 10 seconds worth of application work at a time. Depend=
ing on the performance of the two systems involved, the sizing of the two=
databases, the actual transaction load and how well the two databases ar=
e tuned and maintained, this catchup process can be a matter of minutes, =
hours, or eons.
>=20
> You have now successfully set up your first basic master/slave replicat=
ion system, and the 2 databases should, once the slave has caught up, con=
tain identical data. That's the theory, at least. In practice, it's good =
to build confidence by verifying that the datasets are in fact the same.
>=20
> The following script will create ordered dumps of the 2 databases and c=
ompare them. Make sure that pgbench has completed its testing, and that y=
our slon sessions have caught up.=20
>=20
> #!/bin/sh
> echo -n "**** comparing sample1 ... "
> psql -U $REPLICATIONUSER -h $MASTERHOST $MASTERDBNAME >dump.tmp.1.$$ <<=
_EOF_

> select 'accounts:'::text, aid, bid, abalance, filler
> from accounts order by aid;
> select 'branches:'::text, bid, bbalance, filler
> from branches order by bid;
> select 'tellers:'::text, tid, bid, tbalance, filler
> from tellers order by tid;
> select 'history:'::text, tid, bid, aid, delta, mtime, filler,
> "_Slony-I_$& #123;CLUSTERNAME}_ro
wID"
> from history order by "_Slony-I_$& #123;CLUSTERNAME}_ro
wID";
> _EOF_
> psql -U $REPLICATIONUSER -h $SLAVEHOST $SLAVEDBNAME >dump.tmp.2.$$ <<_E=
OF_
> select 'accounts:'::text, aid, bid, abalance, filler
> from accounts order by aid;
> select 'branches:'::text, bid, bbalance, filler
> from branches order by bid;
> select 'tellers:'::text, tid, bid, tbalance, filler
> from tellers order by tid;
> select 'history:'::text, tid, bid, aid, delta, mtime, filler,
> "_Slony-I_$& #123;CLUSTERNAME}_ro
wID"
> from history order by "_Slony-I_$& #123;CLUSTERNAME}_ro
wID";
> _EOF_
>=20
> if diff dump.tmp.1.$$ dump.tmp.2.$$ >$CLUSTERNAME.diff ; then
> echo "success - databases are equal."
> rm dump.tmp.?.$$
> rm $CLUSTERNAME.diff
> else
> echo "FAILED - see $CLUSTERNAME.diff for database differences"
> fi
> Note that there is somewhat more sophisticated documentation of the pro=
cess in the Slony-I source code tree in a file called slony-I-basic-mstr-=
slv.txt.
>=20
> If this script returns FAILED please contact the developers at http://s=
lony.info/
>=20
>=20
> -----------------------------------------------------------------------=
---------
> Prev Home Next=20
> Defining Slony-I Replication Sets Slon daemons=20
>=20
>=20
> -----------------------------------------------------------------------=
-
>=20
> ____________________
____________________
_______
> Slony1-general mailing list
> Slony1-general- AuKwsB3Fm+ugFIWk8tvy
RWD2FQJk+8+b@public.gmane.org
> http://gborg.postgresql.org/mailman.../slony1-general

--=20
#=3D=3D=3D=3D=3D=3D=
3D=3D=3D=3D=3D=3D=3D
=3D=3D=3D=3D=3D=3D=3
D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3
D=3D=3D=3D=3D=3D=3D=
3D=3D=3D=3D=3D=3D=3D
=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3
D=3D=3D=3D=3D=3D=3D=
3D=3D=3D=3D=3D=3D=3D
=3D#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#=3D=3D=3D=3D=3D=3D=
3D=3D=3D=3D=3D=3D=3D
=3D=3D=3D=3D=3D=3D=3
D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3
D=3D=3D=3D=3D=3D=3D=
3D=3D=3D=3D=3D=3D=3D
=3D=3D=3D=3D=3D=
=3D JanWieck- bwPqjjyvM7QAvxtiuMwx
3w@public.gmane.org #

Sponsored Links