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
unreadable.
> 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.
Check.
> 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
better.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
