Re: Recovery test failure for recovery_min_apply_delay on hamster

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: Recovery test failure for recovery_min_apply_delay on hamster
Дата
Msg-id 20160309032903.GA950702@alvherre.pgsql
обсуждение исходный текст
Ответ на Re: Recovery test failure for recovery_min_apply_delay on hamster  (Michael Paquier <michael.paquier@gmail.com>)
Ответы Re: Recovery test failure for recovery_min_apply_delay on hamster  (Michael Paquier <michael.paquier@gmail.com>)
Список pgsql-hackers
Michael Paquier wrote:
> On Wed, Mar 9, 2016 at 12:14 AM, Alvaro Herrera
> <alvherre@2ndquadrant.com> wrote:
> > Is there anything we can do to short-circuit the wait in the case that
> > replication happens promptly?  A one-minute wait would be acceptable we
> > terminate it early by checking every second.
> 
> After sleeping (best debugger ever) on that, actually a way popped up
> in my mind, and I propose the attached, which refactors a bit 005 and
> checks that the LSN position of master has been applied on standby
> after at least the delay wanted. A maximum delay of 90s is authorized,
> like poll_query_until.

Hmm, okay, that's great.  A question: what happens if the test itself is
slow and the servers are fast, and the test doesn't manage to run two
iterations before the two seconds have elapsed?  This may happen on
overloaded or slow servers, if you're unlucky.

I don't have any ideas on ensuring that we don't apply earlier than the
given period at the moment.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: fun with "Ready for Committer" patches
Следующее
От: Andreas Karlsson
Дата:
Сообщение: Re: Is there a way around function search_path killing SQL function inlining?