Tim,
On Tue, Mar 05, 2002 at 02:48:02PM +0000, Tim Finch, FosterFinch Ltd wrote:
> At 07:50 04/03/2002 -0500, you wrote:
> >3. Try to strace the problem:
>
> I did your 'unlink and copy' procedure then
>
> strace --output=strace.output postmaster -i -D /usr/share/postgresql/data
>
> (not even in background, and all output to stdout)
>
> err. it RAN! I managed to get pgAdmin to connect to it, and even got psql
> working (which you may recall was a previous thread issue with it
> crashing).
Unfortunately, using strace can "fix" problems -- especially timing
related ones. This is due to the fact that strace-ing slows down the
traced process.
> Great! So how do you stop strace?? I ended up killing it from
> another bash screen.
Just killing it fine.
> >Any thing obvious in postmaster.log?
>
> Well here it (below) is at '-d 4', but without strace.output (when I did
> the strace on postmaster it worked so no error messages in log)
>
> [snip]
>
> PGSTAT: connect(2): Connection refused
> DEBUG: proc_exit(1)
> DEBUG: shmem_exit(1)
> DEBUG: exit(1)
I grep-ed the code as follows:
$ find . -name '*.[ch]' | xargs fgrep 'PGSTAT: connect'
./src/backend/postmaster/pgstat.c: perror("PGSTAT: connect(2)");
Hence, postmaster is crapping out at the "if" below:
/* ----------
* pgstat_init() -
*
* Called from postmaster at startup. Create the resources required
* by the statistics collector process.
* ----------
*/
int
pgstat_init(void)
{
..
/*
* Connect the socket to its own address. This saves a few cycles
* by not having to respecify the target address on every send. This
* also provides a kernel-level check that only packets from this same
* address will be received.
*/
if (connect(pgStatSock, (struct sockaddr *) & pgStatAddr, alen) < 0)
{
perror("PGSTAT: connect(2)");
close(pgStatSock);
pgStatSock = -1;
return -1;
}
..
}
Are you configuring postmaster to collect stats?
Sorry, but I cannot reproduce your problem so I cannot debug it further.
Jason