Re: Trying to understand postgres crash - Mailing list pgsql-general

From Hanns Hartman
Subject Re: Trying to understand postgres crash
Date
Msg-id CAO4T218nM-k8YEr5aHsfdMWBPSyEbO=AJ-=DLCLhtC6rvXuQNw@mail.gmail.com
Whole thread Raw
In response to Re: Trying to understand postgres crash  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
On Thu, Dec 22, 2011 at 10:14 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Hanns Hartman <hwhartman@gmail.com> writes:
>> On Thu, Dec 22, 2011 at 7:29 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Best guess is that something sent the background writer process a
>>> SIGUSR2 signal.
>
>> One other thought, my current setup mainly interacts with postgresql
>> via libpq and very rarely via psql.  I have four connections open to
>> postgresql, two of which are connected to one database and two
>> connected to another.  Could that set up or some bad usage of libpq be
>> leading to this signal being generated?
>
> Shouldn't.  You're not running the client-side code as the postgres
> user, are you?  Barring a surprising kernel bug, only postgres-owned
> or root-owned processes could successfully issue kill(SIGUSR2) against
> the background writer process, so that set of processes is where you
> need to look.  I'd first try getting rid of any operations that are
> running under the postgres account but don't really need to do so.
>

Nope the client side code is not running as the postgres user, but it
is running as root.
Unfortunately most daemons in our system run as root.  Also a quick
check or our code base yielded no usages of kill with SIGUSR2.  We do
however use kill with other signals.

I will continue digging, but thanks a lot for the help!  At least I
can narrow down my search a bit ;-)
-HH

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: Trying to understand postgres crash
Next
From: saqib11@igis.nust.edu.pk
Date:
Subject: pgrouting extension with quantum gis