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