Re: pgsql: Test replay of regression tests, attempt II.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Thomas Munro <tmunro(at)postgresql(dot)org>, pgsql-committers <pgsql-committers(at)lists(dot)postgresql(dot)org>
Subject: Re: pgsql: Test replay of regression tests, attempt II.
Date: 2022-01-18 22:19:06
Message-ID: 415981.1642544346@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

Andres Freund <andres(at)anarazel(dot)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.)

> Also, it's odd that there's "max_connections 25" without an equal sign. I'd
> kind of expected that to cause an error....

I see that guc.c intentionally allows the equal sign to be optional.
Too lazy to check if that's documented. It is weird that this one
test appears to be intentionally testing that, though, because it's
sure got nada to do with the expressed purpose of the test.

regards, tom lane

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Thomas Munro 2022-01-18 22:29:04 Re: pgsql: Test replay of regression tests, attempt II.
Previous Message Tom Lane 2022-01-18 22:12:00 Re: pgsql: Modify pg_basebackup to use a new COPY subprotocol for base back