]> granicus.if.org Git - postgresql/commit
Reduce pg_ctl's reaction time when waiting for postmaster start/stop.
authorTom Lane <tgl@sss.pgh.pa.us>
Mon, 26 Jun 2017 19:13:23 +0000 (15:13 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Mon, 26 Jun 2017 19:13:23 +0000 (15:13 -0400)
commitc61559ec3a41ad72a13c18d95b1eee8251de94c6
treed7c7b0c7169e57aab46a591da3174e26885353ff
parent5c77690f6f419c504b7d8248db30c2280217e72e
Reduce pg_ctl's reaction time when waiting for postmaster start/stop.

pg_ctl has traditionally waited one second between probes for whether
the start or stop request has completed.  That behavior was embodied
in the original shell script written in 1999 (commit 5b912b089) and
I doubt anyone's questioned it since.  Nowadays, machines are a lot
faster, and the shell script is long since replaced by C code, so it's
fair to reconsider how long we ought to wait.

This patch adjusts the coding so that the wait time can be any even
divisor of 1 second, and sets the actual probe rate to 10 per second.
That's based on experimentation with the src/test/recovery TAP tests,
which include a lot of postmaster starts and stops.  This patch alone
reduces the (non-parallelized) runtime of those tests from ~4m30s to
~3m5s on my machine.  Increasing the probe rate further doesn't help
much, so this seems like a good number.

In the real world this probably won't have much impact, since people
don't start/stop production postmasters often, and the shutdown checkpoint
usually takes nontrivial time too.  But it makes development work and
testing noticeably snappier, and that's good enough reason for me.

Also, by reducing the dead time in postmaster restart sequences, this
change has made it easier to reproduce some bugs that have been lurking
for awhile.  Patches for those will follow.

Discussion: https://postgr.es/m/18444.1498428798@sss.pgh.pa.us
src/bin/pg_ctl/pg_ctl.c