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

Re: New trigger option of pg_standby

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Guillaume Smet <guillaume(dot)smet(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: New trigger option of pg_standby
Date: 2009-03-30 02:32:36
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers

On Fri, Mar 27, 2009 at 9:49 PM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> Uh oh, that's going to be quite tricky with signals. Remember that
> pg_standby is called for each file. A trigger file persists until it's
> deleted, but a signal will only be received by the pg_standby instance that
> happens to be running at the time.

You are right!

> Makes me wonder if the trigger pg_standby with signals is reliable to begin
> with. What if the backend is just processing a file when the signal is
> fired, and there's no pg_standby process running at the moment to receive
> it? Seems like the signaler needs to loop until it has successfully
> delivered the signal to a pg_standby process, which seems pretty ugly.
> Given all the recent trouble with signals, and the fact that it's
> undocumented, perhaps we should just rip out the signaling support from
> pg_standby.

So far, to be frank, I was not sure why the trigger by the signal is necessary
for pg_standby. But, now, I think that it's useful when the user has forgotten
to specify the trigger file. In this case, without the signaling
support, there is
no way to do failover in a short time; probably, the user has to do shutdown
and restart a recovery from the last restart point, which would take time.
So, I'd like to leave the signaling support as a safeguard.

As you pointed out, the "smart" failover by signal would be very tricky. So,
maybe we should not change the existing behavior of pg_standby when
the signal is received.


Fujii Masao
NTT Open Source Software Center

In response to

pgsql-hackers by date

Next:From: Andrew GierthDate: 2009-03-30 03:15:03
Subject: Re: TupleTableSlot API problem
Previous:From: Alvaro HerreraDate: 2009-03-30 02:01:03
Subject: Re: Re: [COMMITTERS] pgsql: Temporarily (I hope) disableflattening of IN/EXISTS sublinks

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