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

From Michael Paquier
Subject Re: SKIP_LOCKED test causes random buildfarm failures
Date
Msg-id 20191107013942.GA1768@paquier.xyz
Whole thread Raw
In response to Re: SKIP_LOCKED test causes random buildfarm failures  (Andres Freund <andres@anarazel.de>)
Responses Re: SKIP_LOCKED test causes random buildfarm failures  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Nov 06, 2019 at 03:01:11PM -0800, Andres Freund wrote:
> I don't know what lead us to doing so, but it doesn't seem reasonable to
> allow the user to see whether the table has actually been vacuumed. I
> would assume that one uses SKIP_LOCKED partially to avoid unnecessary
> impacts in production due to other tasks starting to block on e.g. a
> VACUUM FULL, even though without the "ordered queueing" everything could
> just go on working fine. I'm not sure that indicates whether WARNING or
> NOTICE is the best choice.

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.

> So I'd be inclined to go with the client_min_messages approach?

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?
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: ssl passphrase callback
Next
From: Amit Langote
Date:
Subject: Re: [PATCH] Do not use StdRdOptions in Access Methods