Heikki Linnakangas wrote:
Ok, I've committed a minimal patch to pg_standby in CVS HEAD and
REL8_3_STABLE to not interpret SIGQUIT as a signal for failover. I
added a signal handler for SIGUSR1 to trigger failover; that should be
considered the preferred signal for that, even though SIGINT sti
On Wed, Mar 18, 2009 at 5:12 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Mar 18, 2009 at 4:40 PM, Bruce Momjian wrote:
>>> The CVS commit message.
>
>> Is there some reason we don't just put it in the release notes as
>> *part* of the commit? Someone can always go back and edit it late
Robert Haas writes:
> On Wed, Mar 18, 2009 at 4:40 PM, Bruce Momjian wrote:
>> The CVS commit message.
> Is there some reason we don't just put it in the release notes as
> *part* of the commit? Someone can always go back and edit it later.
That was suggested before, and I think we actually tr
On Wed, Mar 18, 2009 at 4:40 PM, Bruce Momjian wrote:
> Heikki Linnakangas wrote:
>> This should be mentioned in release notes, as any script that might be
>> using SIGQUIT at the moment needs to be changed to use SIGUSR1 or SIGINT
>> instead. Where should I make a note of that so that we don't fo
Heikki Linnakangas wrote:
> This should be mentioned in release notes, as any script that might be
> using SIGQUIT at the moment needs to be changed to use SIGUSR1 or SIGINT
> instead. Where should I make a note of that so that we don't forget?
The CVS commit message.
--
Bruce Momjian
Andrew Dunstan wrote:
Heikki Linnakangas wrote:
This should be mentioned in release notes, as any script that might be
using SIGQUIT at the moment needs to be changed to use SIGUSR1 or
SIGINT instead. Where should I make a note of that so that we don't
forget?
Unless I'm missing it the use o
Ok, I've committed a minimal patch to pg_standby in CVS HEAD and
REL8_3_STABLE to not interpret SIGQUIT as a signal for failover. I added
a signal handler for SIGUSR1 to trigger failover; that should be
considered the preferred signal for that, even though SIGINT still works
too.
SIGQUIT is t
Fujii Masao wrote:
Hi,
On Mon, Mar 2, 2009 at 4:59 PM, Heikki Linnakangas
wrote:
Fujii Masao wrote:
On Fri, Feb 27, 2009 at 6:52 PM, Heikki Linnakangas
wrote:
I'm leaning towards option 3, but I wonder if anyone sees a better
solution.
4. Use the shared memory to tell the startup process a
Per discussion, here's a patch for pg_standby in REL8_3_STABLE. The
signal handling is changed so that SIGQUIT no longer triggers failover,
but immediately kills pg_standby, triggering FATAL death of the startup
process too. That's what you want with immediate shutdown.
SIGUSR1 is now accepted
Hi,
On Mon, Mar 2, 2009 at 4:59 PM, Heikki Linnakangas
wrote:
> Fujii Masao wrote:
>>
>> On Fri, Feb 27, 2009 at 6:52 PM, Heikki Linnakangas
>> wrote:
>>>
>>> I'm leaning towards option 3, but I wonder if anyone sees a better
>>> solution.
>>
>> 4. Use the shared memory to tell the startup proce
Zdenek Kotala wrote:
Dne 2.03.09 08:59, Heikki Linnakangas napsal(a):
Fujii Masao wrote:
On Fri, Feb 27, 2009 at 6:52 PM, Heikki Linnakangas
wrote:
I'm leaning towards option 3, but I wonder if anyone sees a better
solution.
4. Use the shared memory to tell the startup process about the
s
Dne 2.03.09 08:59, Heikki Linnakangas napsal(a):
Fujii Masao wrote:
On Fri, Feb 27, 2009 at 6:52 PM, Heikki Linnakangas
wrote:
I'm leaning towards option 3, but I wonder if anyone sees a better
solution.
4. Use the shared memory to tell the startup process about the
shutdown state.
When a
Heikki Linnakangas wrote:
> 1. Implement a custom version of system(3) using fork+exec that let's us
> trap SIGQUIT and send e.g SIGTERM or SIGINT to the child instead. It
> might be a bit tricky to get this right in a portable way; Windows would
> certainly need a completely separate impleme
Fujii Masao wrote:
On Fri, Feb 27, 2009 at 6:52 PM, Heikki Linnakangas
wrote:
I'm leaning towards option 3, but I wonder if anyone sees a better solution.
4. Use the shared memory to tell the startup process about the shutdown state.
When a shutdown signal arrives, postmaster sets the corresp
Hi,
On Fri, Feb 27, 2009 at 6:52 PM, Heikki Linnakangas
wrote:
> We're using SIGQUIT to signal immediate shutdown request. Upon receiving
> SIGQUIT, postmaster in turn kills all the child processes with SIGQUIT and
> exits.
>
> This is a problem when child processes use system(3) to call other pr
Heikki Linnakangas writes:
> Greg Stark wrote:
>> This isn't the first time we've run into the problem that we've run
>> out of signals. I think we need to multiplex all our event signals
>> onto a single signal and use some other mechanism to indicate the type
>> of message.
> Yeah. A patch to d
Greg Stark wrote:
This isn't the first time we've run into the problem that we've run
out of signals. I think we need to multiplex all our event signals
onto a single signal and use some other mechanism to indicate the type
of message.
Yeah. A patch to do that was discussed a while ago, as Fuji
On Fri, Feb 27, 2009 at 9:52 AM, Heikki Linnakangas
wrote:
>
> 2. Use a signal other than SIGQUIT for immediate shutdown of child
> processes. We can't change the signal sent to postmaster for
> backwards-compatibility reasons, but the signal sent by postmaster to child
> processes we could change
We're using SIGQUIT to signal immediate shutdown request. Upon receiving
SIGQUIT, postmaster in turn kills all the child processes with SIGQUIT
and exits.
This is a problem when child processes use system(3) to call other
programs. We use system(3) in two places: to execute archive_command and
19 matches
Mail list logo
