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
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
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
On Wed, Mar 18, 2009 at 4:40 PM, Bruce Momjian br...@momjian.us 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
Robert Haas robertmh...@gmail.com writes:
On Wed, Mar 18, 2009 at 4:40 PM, Bruce Momjian br...@momjian.us 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
On Wed, Mar 18, 2009 at 5:12 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Mar 18, 2009 at 4:40 PM, Bruce Momjian br...@momjian.us wrote:
The CVS commit message.
Is there some reason we don't just put it in the release notes as
*part* of the commit?
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
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
Fujii Masao wrote:
Hi,
On Mon, Mar 2, 2009 at 4:59 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Fujii Masao wrote:
On Fri, Feb 27, 2009 at 6:52 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
I'm leaning towards option 3, but I wonder if anyone sees a
Dne 2.03.09 08:59, Heikki Linnakangas napsal(a):
Fujii Masao wrote:
On Fri, Feb 27, 2009 at 6:52 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
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
heikki.linnakan...@enterprisedb.com wrote:
I'm leaning towards option 3, but I wonder if anyone sees a better
solution.
4. Use the shared memory to
Hi,
On Mon, Mar 2, 2009 at 4:59 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Fujii Masao wrote:
On Fri, Feb 27, 2009 at 6:52 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
I'm leaning towards option 3, but I wonder if anyone sees a better
solution.
Fujii Masao wrote:
On Fri, Feb 27, 2009 at 6:52 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
Hi,
On Fri, Feb 27, 2009 at 6:52 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
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
On Fri, Feb 27, 2009 at 9:52 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
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
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
19 matches
Mail list logo
