Re: pgsql: Test replay of regression tests, attempt II.
От | Andres Freund |
---|---|
Тема | Re: pgsql: Test replay of regression tests, attempt II. |
Дата | |
Msg-id | 20220118230838.amvazn2ig4cf56oy@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: pgsql: Test replay of regression tests, attempt II. (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pgsql: Test replay of regression tests, attempt II.
|
Список | pgsql-committers |
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
В списке pgsql-committers по дате отправления: