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

Re: New trigger option of pg_standby

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Fujii Masao <masao(dot)fujii(at)gmail(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-27 12:49:58
Message-ID: (view raw or whole thread)
Lists: pgsql-hackers
Fujii Masao wrote:
> On Thu, Mar 26, 2009 at 8:54 PM, Guillaume Smet
> <guillaume(dot)smet(at)gmail(dot)com> wrote:
>> On Thu, Mar 26, 2009 at 11:50 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>> I like the idea of removing -t and adding 2 new options so that people
>> are warned about the intended behavior.
> OK, I'll change the patch as Simon suggested; removing -t and adding
> two new options: -f = fast failover (existing behavior), -p patient failover.
> Also I'll default the patient failover, so it's performed when the signal
> (SIGINT or SIGUSR1) is received.

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.

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 

   Heikki Linnakangas

In response to


pgsql-hackers by date

Next:From: Sergey KonoplevDate: 2009-03-27 13:04:06
Subject: Re: Crash in gist insertion on pathological box data
Previous:From: Greg StarkDate: 2009-03-27 12:46:32
Subject: Re: SSL over Unix-domain sockets

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