On 2/15/2005 2:46 PM, Juanky Moral wrote:

> 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

signal 11 is usually segmentation violation and causes a core dump. You 
should find that core file in the database directory (underneath 
data/base). If not, your smartass-package-maintainer has somehow managed 
to set the ulimit for core files to zero. Slap him, correct the problem, 
get a core dump and produce a stack backtrace.


Jan

> 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 #
>> 
> 
> 


-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck at Yahoo.com #