Hi,
On 2022-01-18 17:19:06 -0500, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> 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