On 8/3/22 2:08 PM, Peter Geoghegan wrote:
> On Wed, Aug 3, 2022 at 1:47 PM Tom Lane <tgl@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
