Re: Latches, signals, and waiting

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: Latches, signals, and waiting
Дата
Msg-id 4C90D4BF.3020304@enterprisedb.com
обсуждение исходный текст
Ответ на Latches, signals, and waiting  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Latches, signals, and waiting  (Fujii Masao <masao.fujii@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Latches, signals, and waiting
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: [COMMITTERS] pgsql: Use a latch to make startup process wake up and replay