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: 49CCCB76.4080305@enterprisedb.com (view raw or flat)
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 
pg_standby.

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com

In response to

Responses

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-2014 The PostgreSQL Global Development Group