Re: Increasing timeout of poll_query_until for TAP tests

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Increasing timeout of poll_query_until for TAP tests
Date: 2018-01-01 10:55:37
Message-ID: 20180101105537.GA4733@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Dec 31, 2017 at 09:52:27PM -0800, Noah Misch wrote:
> Since now() is transaction_timestamp(), $recovery_time precedes or equals
> $lsn3, and this didn't close the race. Using clock_timestamp() here would
> work, as does using separate transactions like recovery-test-fixes.patch did.
> I'll shortly push a fix for this and a similar ordering problem in the
> standby_5 test, which first appeared subsequent to this thread.

As recovery_target_inclusive is true by default, my conclusion on the
matter, which was something that my tests on hamster, the now-dead
buildfarm animal seemed to confirm, is that just getting a timestamp at
least the value of the LSN from the same transaction was enough to fix
all the failures. And hamster was really slow. I can follow why
logically your patch makes sense, so I agree that this is sane. Have you
spotted failures from the buildfarm? This is hard to spot from any
people which just have access to what the buildfarm UI offers, so any
reference to failures on this thread would be welcome.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tels 2018-01-01 12:26:01 Re: What does Time.MAX_VALUE actually represent?
Previous Message Ashutosh Bapat 2018-01-01 10:12:16 Re: [HACKERS] Transactions involving multiple postgres foreign servers