On Thu, Dec 22, 2011 at 10:14 AM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: > Hanns Hartman <hwhartman@xxxxxxxxx> writes: >> On Thu, Dec 22, 2011 at 7:29 AM, Tom Lane <tgl@xxxxxxxxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
