aboutsummaryrefslogtreecommitdiff
path: root/src/backend/executor/nodeModifyTable.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2017-06-26 19:01:26 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2017-06-26 19:01:26 -0400
commit2710ccd782d0308a3fa1ab193531183148e9b626 (patch)
tree35028f431f421056b2244fe7cc50e278141fc78d /src/backend/executor/nodeModifyTable.c
parente5d494d78cf6c60f04a5d3f571205f452a78d81f (diff)
downloadpostgresql-2710ccd782d0308a3fa1ab193531183148e9b626.tar.gz
postgresql-2710ccd782d0308a3fa1ab193531183148e9b626.zip
Reduce wal_retrieve_retry_interval in applicable TAP tests.
By default, wal_retrieve_retry_interval is five seconds, which is far more than is needed in any of our TAP tests, leaving the test cases just twiddling their thumbs for significant stretches. Moreover, because it's so large, we get basically no testing of the retry-before- master-is-ready code path. Hence, make PostgresNode::init set up wal_retrieve_retry_interval = '500ms' as part of its customization of test clusters' postgresql.conf. This shaves quite a few seconds off the runtime of the recovery TAP tests. Back-patch into 9.6. We have wal_retrieve_retry_interval in 9.5, but the test infrastructure isn't there. Discussion: https://postgr.es/m/31624.1498500416@sss.pgh.pa.us
Diffstat (limited to 'src/backend/executor/nodeModifyTable.c')
0 files changed, 0 insertions, 0 deletions