> Hong Yuan wrote:
...
> > A week ago, I move the database to another machine and made the
> > necessary modification to slon configuration and the system runs
> > smoothly for a while. However, when today I checked the master
> node, I
> > find a bunch of slon processes instead of one, which is the number
> I
> > usually find.


> > ws2:~# ps -Af | grep slon
> > root      6654  3121  0 12:56 pts/2    00:00:00 slon slontest
> > root      6656  6654  0 12:56 pts/2    00:00:00 slon slontest
> > root      6657  6656  0 12:56 pts/2    00:00:00 slon slontest
> > root      6658  6656  0 12:56 pts/2    00:00:00 slon slontest
> > root      6660  6656  0 12:56 pts/2    00:00:00 slon slontest
> > root      6661  6656  0 12:56 pts/2    00:00:00 slon slontest
> > root      6662  6656  0 12:56 pts/2    00:00:00 slon slontest
> > root      6663  6656  0 12:56 pts/2    00:00:00 slon slontest
> > root      6851  4307  0 13:20 pts/7    00:00:00 grep slon

> On Linux, it is common for threads to be listed in the process table
> as if they were processes.
> slon is a multithreaded process, so it could, in that case, appear
> as though it was being listed in the process table as many times as
> there are threads + processes...

> Date: Mon, 29 Aug 2005 20:24:27 -0700
> From: Alan Hodgson <ahodgson at simkin.ca>
> Subject: Re: [Slony1-general] Multiple slon processes for the same
> 	replication
> To: slony1-general at gborg.postgresql.org
> Message-ID: <20050830032427.GA26611 at simkin.ca>
> Content-Type: text/plain; charset=us-ascii
> 
> On Tue, Aug 30, 2005 at 09:55:19AM +0800, Hong Yuan wrote:
> > What could be the reason that the output of 'ps' command changes?
> What 
> > causes slon to spawn multiple threads? On my slave machine for
> example, 
> > there is still only one 'slon' entry using the same 'ps -Af'?
> 
> 
> I would expect you're using a different version of ps.  Try ps -am.

Note that in the original "ps" output, it's clearly a list of separate
processes. "ps am" output would make that clear (threads show up with
"-" for a pid). And the original poster didn't do that (nor "ps H").
Don't think there's any way to hack $PS_PERSONALITY to get such
behaviour invisibly, either.

Any chance, Hong Yuan, that slon could (and had reason to listen to)
make use of network paths to other boxes that it didn't have before?
Is this condition continuing? Care to do a "ps -Haf | egrep slon" ?