Обсуждение: slony replication issue

I use  slony version "slony1-1.2.20" , and postgresql version 9.1
I am using slony replica Master DB to Slave DB
The issue I got , when I created cluster on Master DB  , then insert one ro=
w for the replica table , it will got below log , But if I drop the cluster=
 , it can do insert ,delete and update . Can you help me to solve out this =
issue . I have attached the cat cluster_setup.sh script. Again , I have not=
 started to test replica .

---------------------------------------------------------------------------=
---------------------------------
LOG:  server process (PID 30019) was terminated by signal 11: Segmentation =
fault
LOG:  terminating any other active server processes
WARNING:  terminating connection because of crash of another server process
DETAIL:  The postmaster has commanded this server process to roll back the =
current transaction and exit, because another server process exited abnorma=
lly and possibly corrupted shared memory.
HINT:  In a moment you should be able to reconnect to the database and repe=
at your command.
WARNING:  terminating connection because of crash of another server process
DETAIL:  The postmaster has commanded this server process to roll back the =
current transaction and exit, because another server process exited abnorma=
lly and possibly corrupted shared memory.
HINT:  In a moment you should be able to reconnect to the database and repe=
at your command.
WARNING:  terminating connection because of crash of another server process
DETAIL:  The postmaster has commanded this server process to roll back the =
current transaction and exit, because another server process exited abnorma=
lly and possibly corrupted shared memory.
HINT:  In a moment you should be able to reconnect to the database and repe=
at your command.
WARNING:  terminating connection because of crash of another server process
DETAIL:  The postmaster has commanded this server process to roll back the =
current transaction and exit, because another server process exited abnorma=
lly and possibly corrupted shared memory.
HINT:  In a moment you should be able to reconnect to the database and repe=
at your command.
WARNING:  terminating connection because of crash of another server process
DETAIL:  The postmaster has commanded this server process to roll back the =
current transaction and exit, because another server process exited abnorma=
lly and possibly corrupted shared memory.
HINT:  In a moment you should be able to reconnect to the database and repe=
at your command.
FATAL:  the database system is in recovery mode
WARNING:  terminating connection because of crash of another server process
DETAIL:  The postmaster has commanded this server process to roll back the =
current transaction and exit, because another server process exited abnorma=
lly and possibly corrupted shared memory.
HINT:  In a moment you should be able to reconnect to the database and repe=
at your command.
LOG:  all server processes terminated; reinitializing
LOG:  database system was interrupted; last known up at 2012-03-02 16:27:31=
 CST
LOG:  database system was not properly shut down; automatic recovery in pro=
gress
FATAL:  the database system is in recovery mode
LOG:  consistent recovery state reached at 0/BA3A740
---------------------------------------------------------------------------=
---------------------------------




-bash-3.2$ cat cluster_setup.sh
#!/bin/sh

CLUSTER=3Dedu_cluster
DB1=3Dedu_ngc
DB2=3Dedu_slave
H1=3Dlocalhost
H2=3Dlocalhost
U1=3Dngc
P1=3Dngc
U2=3Dpostgres
P2=3Dedu2012

slonik <<_EOF_

cluster name =3D $CLUSTER;

node 1 admin conninfo =3D 'dbname=3D$DB1 host=3D$H1 user=3D$U1';
node 2 admin conninfo =3D 'dbname=3D$DB2 host=3D$H2 user=3D$U2';

init cluster (id =3D 1, comment =3D 'Master Node');

create set (id =3D 1, origin =3D 1, comment =3D 'All edu_ngc tables');
set add table (set id =3D 1, origin =3D 1, id =3D 1, full qualified name =
=3D 'public.test_rep', comment =3D 'Table test_ngc');


store node (id =3D 2, comment =3D 'Slave node', event node=3D1);
store path (server =3D 1, client =3D 2, conninfo =3D 'dbname=3D$DB1 host=3D=
$H1 user=3D$U1');
store path (server =3D 2, client =3D 1, conninfo =3D 'dbname=3D$DB2 host=3D=
$H2 user=3D$U2');

store listen (origin =3D 1, provider =3D 1, receiver =3D 2);
store listen (origin =3D 2, provider =3D 2, receiver =3D 1);
_EOF_
-bash-3.2$






This message contains information that may be privileged or confidential an=
d is the property of the Capgemini Group. It is=20
intended only for the person to whom it is addressed. If you are not the in=
tended recipient, you are not authorized to=20
read, print, retain, copy, disseminate, distribute, or use this message or =
any part thereof. If you receive this message=20
in error, please notify the sender immediately and delete all copies of thi=
s message.

On Fri, Mar 2, 2012 at 4:15 AM, Nie, Guocong <guocong.nie@capgemini.com> wr=
ote:
> I use =A0slony version =93slony1-1.2.20=94 , and postgresql version 9.1

You should really take this over to the Slony mailing list, it's not a
generic Postgres problem.

http://lists.slony.info/mailman/listinfo/slony1-general

> LOG:=A0 server process (PID 30019) was terminated by signal 11: Segmentat=
ion
> fault

It seems pretty likely that this indicates some problem with compiling
the C functions for the log triggers.  If something goes wrong (which
is a broad matter), and the function accesses an undefined chunk of
memory, that would cause that one backend to have a segmentation
fault, which, as it may invalidate shared memory, leads to the
segfault being passed to the postmaster, which then tells all the
other backends of the problem.  Which is consistent with the
phenomenon you are seeing.

I observe that you're running a version that's several years old,
which predates Postgres 9.1.

Version 1.2.20 of Slony was released in December 2009, which was
before either Postgres 9.0 *or* 9.1 were released.   And commonly,
enough header stuff changes that we have usually needed to make some
minor modifications to get versions of Slony to work with new PG
releases.

I would not expect 1.2.20 to be compatible with Postgres 9.1, and it's
an ancient enough branch that we're not doing much with 1.2 to try to
keep it compatible.  I wouldn't recommend using 1.2.20, certainly not
for a new installation.  You might want to try Slony 2.0 (better) or
2.1 (quite a lot further better).
--=20
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"