Re: SKIP_LOCKED test causes random buildfarm failures

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: SKIP_LOCKED test causes random buildfarm failures
Date: 2019-11-07 01:39:42
Message-ID: 20191107013942.GA1768@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 Content-Type Size
vacuum-lock-tests.patch text/x-diff 2.5 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2019-11-07 01:49:38 Re: [PATCH] Do not use StdRdOptions in Access Methods
Previous Message Bruce Momjian 2019-11-07 01:23:56 Re: ssl passphrase callback