Re: Latches, signals, and waiting - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Latches, signals, and waiting
Date
Msg-id 4C90D4BF.3020304@enterprisedb.com
Whole thread Raw
In response to Latches, signals, and waiting  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Latches, signals, and waiting
List pgsql-hackers
On 15/09/10 16:55, Tom Lane wrote:
> So I'm wondering if we couldn't eliminate the five-second sleep
> requirement here too.  It's problematic anyhow, since somebody looking
> for energy efficiency will still feel it's too short, while somebody
> concerned about fast failover will feel it's too long.

Yep.

>  Could the
> standby triggering protocol be modified so that it involves sending a
> signal, not just creating a file?

Seems reasonable, at least if we still provide an option for more 
frequent polling and no need to send signal.

> (One issue is that it's not clear what that'd translate to on Windows.)

pg_ctl failover ? At the moment, the location of the trigger file is 
configurable, but if we accept a constant location like 
"$PGDATA/failover" pg_ctl could do the whole thing, create the file and 
send signal. pg_ctl on Window already knows how to send the "signal" via 
the named pipe signal emulation.

Fujii-san suggested that we might have a user-defined function for 
triggering failover as well. That's also handy, but it's not a 
replacement because it only works in hot standby mode.

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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Latches, signals, and waiting
Next
From: Simon Riggs
Date:
Subject: Re: [COMMITTERS] pgsql: Use a latch to make startup process wake up and replay