On 8/3/22 2:08 PM, Peter Geoghegan wrote:
On Wed, Aug 3, 2022 at 1:47 PM Tom Lane <t...@sss.pgh.pa.us> wrote:
Again, this seems to me to be breaking the test's real-world applicability
for a (false?) sense of stability.
I agree.
A lot of the VACUUM test flappiness issues we've had to deal with in
the past now seem like problems with VACUUM itself, the test's design,
or both. For example, why should we get a totally different
pg_class.reltuples because we couldn't get a cleanup lock on some
page? Why not just make sure to give the same answer either way,
which happens to be the most useful behavior to the user? That way
the test isn't just targeting implementation details.
After catching up (and reviewing approaches that could work while on
poor wifi), it does make me wonder if we can have a useful test ready
before beta 3.
I did rule out wanting to do the "xid + $X" check after reviewing some
of the output. I think that both $X could end up varying, and it really
feels like a bandaid.
Andres suggested upthread using "txid_current()" -- for the comparison,
that's one thing I looked at. Would any of the XID info from
"pg_control_checkpoint()" also serve for this test?
If yes to the above, I should be able to modify this fairly quickly.
Jonathan
