From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PostgresNode::poll_query_until hacking |
Date: | 2017-07-03 00:46:21 |
Message-ID: | CAB7nPqReOiSfQyPJWO_26yCMsoyHr+cG6Lq+9GaNfrmWLOPfew@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2017-07-03 01:15:15 | Re: Race-like failure in recovery/t/009_twophase.pl |
Previous Message | Michael Paquier | 2017-07-03 00:28:05 | Re: pg_ctl wait exit code (was Re: [COMMITTERS] pgsql: Additional tests for subtransactions in recovery) |