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

Re: pg_ctl failover Re: Latches, signals, and waiting

From: Tatsuo Ishii <ishii(at)postgresql(dot)org>
To: masao(dot)fujii(at)gmail(dot)com
Cc: magnus(at)hagander(dot)net, heikki(dot)linnakangas(at)enterprisedb(dot)com, itagaki(dot)takahiro(at)gmail(dot)com, tgl(at)sss(dot)pgh(dot)pa(dot)us, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_ctl failover Re: Latches, signals, and waiting
Date: 2011-01-31 04:06:59
Message-ID: 20110131.130659.856152966720343416.t-ishii@sraoss.co.jp (view raw or flat)
Thread:
Lists: pgsql-hackers
> On Mon, Jan 31, 2011 at 12:35 PM, Tatsuo Ishii <ishii(at)postgresql(dot)org> wrote:
>>> If the "pg_ctl promote" patch will have been committed, I recommend that
>>> the C function should send the signal to the startup process rather than
>>> creating the trigger file. Because the trigger file is checked every for 5s,
>>> which would lengthen the failover time by an average 2.5s.
>>
>> Ok, probably I could make the function smart enough to signal or not
>> by looking at the PostgreSQL version.
>>
>> BTW is it possible to export following variable in xlog.c?
>>
>> static char *TriggerFile = NULL;
>>
>> That would make coding of the C function lot easier.
> 
> If you change the function so that it sends the signal or call
> system("pg_ctl promote"), exporting that variable seems to
> be unnecessary. Because pg_ctl promote can promote
> the server even if trigger_file is not supplied. You don't need
> to check whether trigger_file is set or not, in the C function.

True.

BTW for 9.0, perhaps copy&paste parseRecoveryCommandFileLine() from
xlog.c into the C function is the only way to go.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp

In response to

pgsql-hackers by date

Next:From: Robert HaasDate: 2011-01-31 04:41:36
Subject: Re: Spread checkpoint sync
Previous:From: Fujii MasaoDate: 2011-01-31 03:49:45
Subject: Re: pg_ctl failover Re: Latches, signals, and waiting

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