On Sun, Jul 2, 2017 at 4:53 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> The attached proposed patch changes the TAP test infrastructure's
> poll_query_until function in two ways:
> 1. An optional argument is added to allow specifying the query result
> value we're waiting for, overriding the normal "t".  This allows
> folding a handwritten delay loop in 007_sync_rep.pl into the
> poll_query_until ecosystem.

True that in this test the expected output can be quite complicated,
so turning that into a query that returned 't' would make the code

> As far as I've found, there are no other
> handwritten delay loops in the TAP tests.

Good catch. Yes here using a poll_query_until call makes sense.

> 2. poll_query_until is modified to probe 10X per second not once
> per second, in keeping with the changes I've been making elsewhere
> to remove not-carefully-analyzed 1s delays in the regression tests.
> On my workstation, the reduced probe delay shaves a useful amount
> of time off the recovery and subscription regression tests.  I also
> tried it on dromedary, which is about the slowest hardware I'd care
> to run the TAP tests on regularly, and it seems to be about a wash
> there --- some tests get faster, but some get slower, presumably due
> to more overhead from the probe queries.


> Thoughts?

-   is($result, $expected, $msg);
+   ok( $self->poll_query_until('postgres', $check_sql, $expected), $msg);
A matter of taste here: using a space after "ok(".

If you would like to get some feedback from me, waiting until Monday
morning my time (Sunday evening yours) before pushing patches would be

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to