Thanks for your anwer, Jan.
I'm still fighting against the problem (and looking for a solution).
No coredump in anywhere. I recompiled postgres again with
--enable-thread-safety, thinking it could be the reason. Also I
re-adjust shared_buffers, max_connections to low values, but the
result are the same: all works fine until the master is updated
(insert/delete/update). At this moment, psql crash and master slone
process dies.

Here is my postgres.log:

LOG:  database system is ready
NOTICE:  type "_epvnet.xxid" is not yet defined
DETAIL:  Creating a shell type definition.
NOTICE:  argument type _epvnet.xxid is only a shell
NOTICE:  type "_epvnet.xxid_snapshot" is not yet defined
DETAIL:  Creating a shell type definition.
NOTICE:  argument type _epvnet.xxid_snapshot is only a shell
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index
"sl_node-pkey" for table "sl_node"
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index
"sl_set-pkey" for table "sl_set"
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index
"sl_setsync-pkey" for table "sl_setsync"
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index
"sl_table-pkey" for table "sl_table"
NOTICE:  CREATE TABLE / UNIQUE will create implicit index
"sl_table_tab_reloid_key" for table "sl_table"
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index
"sl_trigger-pkey" for table "sl_trigger"
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index
"sl_sequence-pkey" for table "sl_sequence"
NOTICE:  CREATE TABLE / UNIQUE will create implicit index
"sl_sequence_seq_reloid_key" for table "sl_sequence"
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index
"sl_path-pkey" for table "sl_path"
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index
"sl_listen-pkey" for table "sl_listen"
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index
"sl_subscribe-pkey" for table "sl_subscribe"
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index
"sl_event-pkey" for table "sl_event"
NOTICE:  Slony-I: removing stale pg_listener entry for pid 23908,
relname _epvnet_Restart
NOTICE:  Slony-I: removing stale pg_listener entry for pid 23923,
relname _epvnet_Node_1
NOTICE:  Slony-I: removing stale pg_listener entry for pid 23944,
relname _epvnet_Node_2
NOTICE:  Slony-I: removing stale pg_listener entry for pid 24014,
relname _epvnet_Node_2
NOTICE:  Slony-I: removing stale pg_listener entry for pid 23944,
relname _epvnet_Confirm
LOG:  server process (PID 31858) was terminated by signal 11
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 abnormally and possibly corrupted shared memory.
HINT:  In a moment you should be able to reconnect to the database and
repeat your command.
FATAL:  the database system is in recovery mode

Thanks in advance,
Juanky Moral


On Tue, 08 Feb 2005 18:38:54 -0500, Jan Wieck <JanWieck at yahoo.com> wrote:
> On 2/8/2005 2:49 PM, Juanky Moral wrote:
> 
> > Hi all.
> > My name is Juanky Moral. I've read all the documents (at Gborg,
> > General Bits articles, ...) , and many posts to slony-general as
> > possible, but I still need your help:
> >
> > I build and installed slony1-1.0.5 to try replicate a small database
> > (11 tables, 5 sequences).
> > All the tables are keyed_tables.
> > I've configured a simple cluster: one master - one slave.
> > All things seem to work fine, but when I try to do any update on
> > master (using psql) for testing purposes, psql client aborts and local
> > slon process die.
> > This is what I see in the log.out:
> 
> It's not Slony that's crashing here. For some reason a database backend
> dies the hard way and the postmaster reaction to that is to kill all
> other database connections and reinitialize shared memory.
> 
> You should find a coredump in the database directory and if your
> postgres was compiled with debugging information a stack backtrace will
> lead to the answer why that backend crashed.
> 
> Jan
> 
> >
> > CONFIG main: slon version 1.0.5 starting up
> > CONFIG main: local node id = 1
> > CONFIG main: loading current cluster configuration
> > CONFIG storeNode: no_id=2 no_comment='node2 en fernando'
> > CONFIG storePath: pa_server=2 pa_client=1 pa_conninfo="dbname=estafeta
> > host=fernando user=postgres" pa_connretry=10
> > CONFIG storeListen: li_origin=2 li_receiver=1 li_provider=2
> > CONFIG storeSet: set_id=1 set_origin=1 set_comment='tablas estafeta'
> > CONFIG main: configuration complete - starting threads
> > CONFIG enableNode: no_id=2
> > 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 abnormally and possibly corrupted shared memory.
> > HINT:  In a moment you should be able to reconnect to the database and
> > repeat your command.
> > FATAL  syncThread: "start transaction;set transaction isolation level
> > serializable;select last_value from "_epvnet".sl_action_seq;" - server
> > closed the connection unexpectedly
> >       This probably means the server terminated abnormally
> >       before or while processing the request.
> > 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 abnormally and possibly corrupted shared memory.
> > HINT:  In a moment you should be able to reconnect to the database and
> > repeat your command.
> > FATAL  localListenThread: cannot start transaction - server closed the
> > connection unexpectedly
> >       This probably means the server terminated abnormally
> >       before or while processing the request.
> > INFO   remoteListenThread_2: disconnecting from 'dbname=estafeta
> > host=fernando user=postgres'
> >
> > Misteriously, the same cluster works well in other two nodes (fernando
> > -> isabel).
> > All nodes run PostgreSQL 8.0 (compiled) and Debian GNU/Linux.
> >
> > Thanks in advance,
> >
> 
> --
> #======================================================================#
> # It's easier to get forgiveness for being wrong than for being right. #
> # Let's break this rule - forgive me.                                  #
> #================================================== JanWieck at Yahoo.com #
> 


-- 
Juanky Moral
"Tendr? que moverme m?s r?pido: el horizonte brilla el?ctrico."
(Horizonte El?ctrico - www.losdeltonos.com )