Skip site navigation (1) Skip section navigation (2)

PostgresNode::poll_query_until hacking

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: PostgresNode::poll_query_until hacking
Date: 2017-07-01 19:53:02
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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 into the
poll_query_until ecosystem.  As far as I've found, there are no other
handwritten delay loops in the TAP tests.

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.

I notice that buildfarm member skink (which runs with valgrind)
recently failed a test run due to poll_query_until timing out:

I'm inclined to respond to that either by increasing the fixed
180-second timeout, or by making it configurable from an environment
variable (which Andres would then have to add to skink's configuration).


			regards, tom lane

Attachment: improve-poll_query_until.patch
Description: text/x-diff (3.6 KB)


pgsql-hackers by date

Next:From: Ricky StevensDate: 2017-07-01 20:48:31
Subject: Using postgres planner as standalone component
Previous:From: Fabien COELHODate: 2017-07-01 14:39:08
Subject: Re: WIP Patch: Pgbench Serialization and deadlock errors

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group