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
Re: Increasing timeout of poll_query_until for TAP tests |
Список | 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 по дате отправления: