Postgres Pro
Downloads
Home   >   mailing lists

Thread: trying to track down postgres deaths

trying to track down postgres deaths

From
Geoffrey
Date:
We have a problem with the postgres backend process terminating and
dropping core.  We believe it may be related to another problem we have
where the postgres backend process can not be properly terminated.

Question is, when I see:

#17 0x08151bc5 in ClosePostmasterPorts ()

in the stack trace of the process, is this an indicator that the backend
process was trying to shutdown?

I'm assuming that if it's trying to 'close ports' then it would be
shuting down the process.

Are there multiple scenarios where this routine would be called?

--
Until later, Geoffrey

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety.
  - Benjamin Franklin

Re: trying to track down postgres deaths

From
Tom Lane
Date:
Geoffrey <esoteric@3times25.net> writes:
> Question is, when I see:
> #17 0x08151bc5 in ClosePostmasterPorts ()
> in the stack trace of the process, is this an indicator that the backend
> process was trying to shutdown?

No; that's a function that's executed immediately after fork() to close
postmaster sockets that the backend doesn't need to have open.  It's
highly unlikely that you'd get a crash in there, and even more improbable
that it'd be 17 levels down the call stack.  My bet is that you are
trying to debug with a non-debug-enabled build, and gdb is giving you a
less than accurate stack trace.

Rebuild with --enable-debug, and maybe also --enable-cassert, and see
what you can learn.

            regards, tom lane

Re: trying to track down postgres deaths

From
Geoffrey
Date:
Tom Lane wrote:
> Geoffrey <esoteric@3times25.net> writes:
>> Question is, when I see:
>> #17 0x08151bc5 in ClosePostmasterPorts ()
>> in the stack trace of the process, is this an indicator that the backend
>> process was trying to shutdown?
>
> No; that's a function that's executed immediately after fork() to close
> postmaster sockets that the backend doesn't need to have open.  It's
> highly unlikely that you'd get a crash in there, and even more improbable
> that it'd be 17 levels down the call stack.  My bet is that you are
> trying to debug with a non-debug-enabled build, and gdb is giving you a
> less than accurate stack trace.

This is highly likely as you are correct, we are not running with debug
turned on.  It's on the list, but high availability for these services
has not permitted us to do this.

We know we have a problem with a third party vendor's code we have used
to build into the backend.  It doesn't properly terminate when you run
their application from a shell, thus we are pretty certain this is
causing the problem with the backend processes not properly terminating
when our application terminates.
>
> Rebuild with --enable-debug, and maybe also --enable-cassert, and see
> what you can learn.

Thanks, as noted, that is the plan.

>
>             regards, tom lane
>


--
Until later, Geoffrey

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety.
  - Benjamin Franklin