Re: Increasing timeout of poll_query_until for TAP tests
От | Michael Paquier |
---|---|
Тема | Re: Increasing timeout of poll_query_until for TAP tests |
Дата | |
Msg-id | CAB7nPqQtwOL-2hv_8FSvadz3CyS3AmUWgZ-EBjcfdrjNidcarA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Increasing timeout of poll_query_until for TAP tests (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: Increasing timeout of poll_query_until for TAP tests
|
Список | pgsql-hackers |
On Wed, Aug 3, 2016 at 7:21 AM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > 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? Let me test this.... [... A while after ...] This looks to work properly. 12 runs in a row have passed. -- Michael
В списке pgsql-hackers по дате отправления: