, October 22, 2012 10:21 PM
To: Craig Ringer
Cc: raghu ram; pgsql-admin@postgresql.org; pgsql-general
Subject: Re: [ADMIN] [GENERAL] Streaming Replication Server Crash
Craig Ringer writes:
> On 10/22/2012 08:52 PM, Tom Lane wrote:
>> But having said that, are we sure 10 is SIGUSR1 on the OP&#
On 10/23/2012 01:20 PM, Tom Lane wrote:
>
> This isn't the first time I've wondered exactly which signal was meant
> in a postmaster child-crash report. Seems like it might be worth
> expending some code on a symbolic translation, instead of just printing
> the number. That'd be easy enough (for
Craig Ringer writes:
> On 10/22/2012 08:52 PM, Tom Lane wrote:
>> But having said that, are we sure 10 is SIGUSR1 on the OP's platform?
>> AFAIK, that signal number is not at all compatible across different
>> flavors of Unix. (I see SIGUSR1 is 30 on OS X for instance.)
> Gah. I incorrectly thou
On 10/22/2012 08:52 PM, Tom Lane wrote:
> Craig Ringer writes:
>> On 10/19/2012 04:40 PM, raghu ram wrote:
>>> 2012-10-19 12:26:46 IST [1338]: [18-1] user=,db= LOG: server process
>>> (PID 15565) was terminated by signal 10
>
>> That's odd. SIGUSR1 (signal 10) shouldn't terminate PostgreSQL.
>
Craig Ringer writes:
> On 10/19/2012 04:40 PM, raghu ram wrote:
>> 2012-10-19 12:26:46 IST [1338]: [18-1] user=,db= LOG: server process
>> (PID 15565) was terminated by signal 10
> That's odd. SIGUSR1 (signal 10) shouldn't terminate PostgreSQL.
> Was the server intentionally sent SIGUSR1 by an
On 10/19/2012 04:40 PM, raghu ram wrote:
> Hi All,
>
> We have configured Streaming Replication b/w Primary and Standby server
> and Pgpool-II load balancing module diverting
> SELECT statements to Standby server. As per our observations, Standby
> server crashed during peak hours on today and er
