From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Increasing timeout of poll_query_until for TAP tests |
Date: | 2016-08-03 01:40:23 |
Message-ID: | CAB7nPqQtwOL-2hv_8FSvadz3CyS3AmUWgZ-EBjcfdrjNidcarA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Aug 3, 2016 at 7:21 AM, Alvaro Herrera <alvherre(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2016-08-03 01:58:13 | Re: multivariate statistics (v19) |
Previous Message | Tatsuo Ishii | 2016-08-03 00:41:06 | Re: Slowness of extended protocol |