| Victoria Parsons 2006-01-11, 7:24 am |
| Hi all,
I have a replicating system of just two nodes. The master is on
10.112.0.115, the slave is the one running below. The system was
replicating fine on 6th Jan. Then the slave (the node below) was
shutdown with the power off button, and so didn't have a chance to tidy
up after the slon daemon. You can see from the log that there is no
"shutdown requested" message or any clean up done.
When it was restarted on 9th Jan and 12:55 (master is already up and
running at this point) if fails to delete the old pg_listener entries
and so terminates. This repeats every time the slon daemon is started -
always trying to remove stale pg_listener entries for pids 2733, 2626
and 2627. I double checked these processes were dead, then I went into
postgres and manually deleted all the pg_listener entries for these 3
pids. When I restarted the slon daemon again it worked fine.
I can see from the log that slony has tried to delete these old
pg_listener entries. What I don't know is why it failed. I am running
slony with the superuser "postgres". It was this user I manually deleted
the entries with, so I know its not a permissions problem. Is this a
bug? I don't understand the bit of the error that says "ERROR: tuple
already updated by self" To avoid it happening again I am taking the
precaution of writing a script that removes these entries before
starting the slon daemon. I am interested as to what failed though -
does any one have any thoughts?
By the way I am using 1.1.0 so if this has already been seen and fixed
in a new version I apologise.
Thanks,
Vicki Parsons
2006-01-06 17:32:08 GMT DEBUG1 cleanupThread: 0.068 seconds for
cleanupEvent()
2006-01-06 17:32:08 GMT DEBUG1 cleanupThread: 0.056 seconds for
delete logs
2006-01-09 12:55:01 GMT CONFIG main: slon version 1.1.0 starting up
2006-01-09 12:55:01 GMT CONFIG main: local node id = 1
2006-01-09 12:55:01 GMT CONFIG main: launching sched_start_mainloop
2006-01-09 12:55:01 GMT CONFIG main: loading current cluster
configuration
2006-01-09 12:55:01 GMT CONFIG storeNode: no_id=2 no_comment='CSG
10.112.0.115'
2006-01-09 12:55:01 GMT CONFIG storePath: pa_server=2 pa_client=1
pa_conninfo="dbname=statusdb1 host=10.112.0.115 user=postgres"
pa_connretry=10
2006-01-09 12:55:01 GMT CONFIG storeListen: li_origin=2 li_receiver=1
li_provider=2
2006-01-09 12:55:01 GMT CONFIG storeSet: set_id=1 set_origin=2
set_comment='all status tables'
2006-01-09 12:55:01 GMT WARN remoteWorker_wakeup:
node 2 - no worker
thread
2006-01-09 12:55:01 GMT CONFIG storeSubscribe: sub_set=1 sub_provider=2
sub_forward='f'
2006-01-09 12:55:01 GMT WARN remoteWorker_wakeup:
node 2 - no worker
thread
2006-01-09 12:55:01 GMT CONFIG enableSubscription: sub_set=1
2006-01-09 12:55:01 GMT WARN remoteWorker_wakeup:
node 2 - no worker
thread
2006-01-09 12:55:01 GMT CONFIG main: configuration complete - starting
threads
2006-01-09 12:55:01 GMT DEBUG1 localListenThread: thread starts
NOTICE: Slony-I: removing stale pg_listener entry for pid 2726, relname
_statusdb00e081641f0
2_repcluster_Restart
NOTICE: Slony-I: removing stale pg_listener entry for pid 2733, relname
_statusdb00e081641f0
2_repcluster_Node_1
NOTICE: Slony-I: removing stale pg_listener entry for pid 2727, relname
versions_update
NOTICE: Slony-I: removing stale pg_listener entry for pid 2727, relname
eventlog_insert
NOTICE: Slony-I: removing stale pg_listener entry for pid 2726, relname
_statusdb00e081641f0
2_repcluster_Event
NOTICE: Slony-I: removing stale pg_listener entry for pid 2726, relname
_statusdb00e081641f0
2_repcluster_Event
2006-01-09 12:55:02 GMT FATAL localListenThread: "select
" _statusdb00e081641f0
2_repcluster".cleanupListener(); listen
" _statusdb00e081641f0
2_repcluster_Event"; listen
" _statusdb00e081641f0
2_repcluster_Restart
"; " - ERROR: tuple already
updated by self
2006-01-09 12:55:02 GMT DEBUG1 slon: shutdown requested
This message should be regarded as confidential. If you have received this
email in error please notify the sender and destroy it immediately.
Statements of intent shall only become binding when confirmed in hard copy
by an authorized signatory.
|