Hi, On 2022-01-18 17:19:06 -0500, Tom Lane wrote: > Andres Freund <[email protected]> writes: > > That's an extremely small shared_buffers for running the regression tests, > > it'd not > > be surprising if that provoked problems we don't otherwise see. Perhaps > > VACUUM > > ends up skipping over a page because of page contention? > > Hmm, good thought. I tried running the test with even smaller > shared_buffers, but could not make the reloptions test fall over for > me. But this theory implies a strong timing dependency, so it might > still only happen on particular machines. (If anyone else tries it: > below about 400kB, other tests start failing with "no free unpinned > buffers" and the like.)
I ran the test in a loop for 200+ times now, without reproducing the problem. Rorqual runs on a shared machine though, so it's quite possible that IO will be slower, and thus triggering the issue. I was wondering whether we could use VACUUM VERBOSE for that specific VACUUM - that'd show information about the number of pages with tuples etc. But I don't currently see a way of that causing the regression tests to fail. Even if I set client_min_messages=error, the messages still get sent to the client, because elevel == INFO is special cased in should_output_to_client(). And I don't see a way of redirecting the output of common.c:NoticeProcessor() in psql either. Greetings, Andres Freund
