]> git.ipfire.org Git - thirdparty/postgresql.git/commit
Tighten TAP tests' tracking of postmaster state some more.
authorTom Lane <tgl@sss.pgh.pa.us>
Thu, 20 Jan 2022 22:28:07 +0000 (17:28 -0500)
committerTom Lane <tgl@sss.pgh.pa.us>
Thu, 20 Jan 2022 22:28:07 +0000 (17:28 -0500)
commit17019c00ff48ad9dd6a9d4e4a2a4a5b42d655f57
tree6ea6ebe236e072bdfc1c56156583f4a21df16e2d
parent0a79feeca718f6934f57672ae4a5846f3da3d159
Tighten TAP tests' tracking of postmaster state some more.

Commits 6c4a8903b et al. had a couple of deficiencies:

* The logic I added to Cluster::start to see if a PID file is present
could be fooled by a stale PID file left over from a previous
postmaster.  To fix, if we're not sure whether we expect to find a
running postmaster or not, validate the PID using "kill 0".

* 017_shm.pl has a loop in which it just issues repeated Cluster::start
calls; this will fail if some invocation fails but leaves self->_pid
set.  Per buildfarm results, the above fix is not enough to make this
safe: we might have "validated" a PID for a postmaster that exits
immediately after we look.  Hence, match each failed start call with
a stop call that will get us back to the self->_pid == undef state.
Add a fail_ok option to Cluster::stop to make this work.

Discussion: https://postgr.es/m/CA+hUKGKV6fOHvfiPt8=dOKzvswjAyLoFoJF1iQXMNpi7+hD1JQ@mail.gmail.com
src/test/perl/PostgresNode.pm
src/test/recovery/t/017_shm.pl