Re: PostgresNode::poll_query_until hacking

On Sun, Jul 2, 2017 at 4:53 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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