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
