Re: Increasing timeout of poll_query_until for TAP tests

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: Increasing timeout of poll_query_until for TAP tests
Дата
Msg-id 20160802222103.GA602448@alvherre.pgsql
обсуждение исходный текст
Ответ на Re: Increasing timeout of poll_query_until for TAP tests  (Michael Paquier <michael.paquier@gmail.com>)
Ответы Re: Increasing timeout of poll_query_until for TAP tests  (Michael Paquier <michael.paquier@gmail.com>)
Re: Increasing timeout of poll_query_until for TAP tests  (Noah Misch <noah@leadboat.com>)
Список pgsql-hackers
Michael Paquier wrote:

> Here using pg_xlog_replay_resume() is not the correct solution because
> this would cause the node to finish recovery before we want it to, and
> so is recovery_target_action = 'promote'. If we look at the test, it
> is doing the following when getting the TXID that is used as recovery
> target:
> $node_master->safe_psql('postgres',
>         "INSERT INTO tab_int VALUES (generate_series(1001,2000))");
> my $recovery_txid =
>   $node_master->safe_psql('postgres', "SELECT txid_current()");
> my $lsn2 =
>   $node_master->safe_psql('postgres', "SELECT pg_current_xlog_location();");
> What I think we had better do is reverse the calls
> pg_current_xlog_location() and txid_current() so as we are sure that
> the LSN we track for replay is lower than the real target LSN. The
> same problem exists when defining the timestamp target.
>
> The patch attached does that,

Why not capture both items in a single select, such as in the attached
patch?

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

Вложения

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

Предыдущее
От: "David G. Johnston"
Дата:
Сообщение: Re: Fwd: [BUGS] BUG #14247: COMMENT is restored on wrong database
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Double invocation of InitPostmasterChild in bgworker with -DEXEC_BACKEND