Skip site navigation (1) Skip section navigation (2)

Re: Immediate shutdown and system(3)

From: Greg Stark <stark(at)enterprisedb(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>
Subject: Re: Immediate shutdown and system(3)
Date: 2009-02-27 10:49:11
Message-ID: 4136ffa0902270249h73ab7880v476811954e59f928@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Fri, Feb 27, 2009 at 9:52 AM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)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 child
> processes we could change. We've already used all signals in normal
> backends, but perhaps we could rearrange them.

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.

Perhaps we do need two signals though, so subprocesses don't need to
connect to shared memory to distinguish "exit now" from other events.
SIGINT for "exit now" and USR1 for every postgres-internal signal
using shared memory to determine the meaning sounds like the most
logical arrangement to me.

Do we really need a "promote to master" message at all? Is pg_standby
responsible for this or could the master write out the configuration
changes necessary itself?

-- 
greg

In response to

Responses

pgsql-hackers by date

Next:From: Zeugswetter Andreas OSB sITDate: 2009-02-27 11:15:57
Subject: RE: [HACKERS] RE: [HACKERS] Kerberos V5 required for PostgreSQL installation on Windows
Previous:From: Heikki LinnakangasDate: 2009-02-27 10:47:50
Subject: Hot Standby - >8.5

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group