Re: SKIP_LOCKED test causes random buildfarm failures - Mailing list pgsql-hackers

From Tom Lane
Subject Re: SKIP_LOCKED test causes random buildfarm failures
Date
Msg-id 5815.1573756664@sss.pgh.pa.us
Whole thread Raw
In response to Re: SKIP_LOCKED test causes random buildfarm failures  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: SKIP_LOCKED test causes random buildfarm failures  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
I wrote:
> Michael Paquier <michael@paquier.xyz> writes:
>> Good question.  That's a historical choice, still I have seen cases
>> where those warnings are helpful while not making the logs too
>> verbose to see some congestion in the jobs.

> I kind of feel that NOTICE is more semantically appropriate, but
> perhaps there's an argument for keeping it at WARNING.

Well, I'm not hearing any groundswell of support for changing the
message level, so let's leave that as-is and just see about
stabilizing the tests.

>> The main purpose of the tests in regress/ is to check after the
>> grammar, so using client_min_messages sounds like a plan.  We have
>> a second set of tests in isolation/ where I would actually like to
>> disable autovacuum by default on a subset of tables.  Thoughts about
>> the attached?

After looking more closely at the isolation test, I agree that adding
the "ALTER TABLE ... SET (autovacuum_enabled = false)" bits to it is
a good idea.  The LOCK operations should make that irrelevant for
part1, but there's at least a theoretical hazard for part2.
(Actually, is "autovacuum_enabled = false" really sufficient to
keep autovacuum away?  It'd probably lock the table for long enough
to examine its reloptions, so it seems like all we're doing here is
reducing the window for trouble a little bit.  Still, maybe that's
worthwhile.)

As for the SKIP_LOCKED tests in vacuum.sql, what I now propose is that
we just remove them.  I do not see that they're offering any coverage
that's not completely redundant with this isolation test.  We don't
need to spend cycles every day on that.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Mark Dilger
Date:
Subject: Re: Using multiple extended statistics for estimates
Next
From: Alvaro Herrera
Date:
Subject: Re: format of pg_upgrade loadable_libraries warning