From: | "Bossart, Nathan" <bossartn(at)amazon(dot)com> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com> |
Subject: | Re: [Proposal] Allow users to specify multiple tables in VACUUM commands |
Date: | 2017-09-27 16:20:43 |
Message-ID: | FABB745C-F6F8-436B-9872-6C1495A8137E@amazon.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Here's a v22. Beyond a rebase, the only real difference is some cleanup
in the test cases.
On 9/26/17, 1:38 PM, "Bossart, Nathan" <bossartn(at)amazon(dot)com> wrote:
> On 9/25/17, 12:42 AM, "Michael Paquier" <michael(dot)paquier(at)gmail(dot)com> wrote:
>> + if (!IsAutoVacuumWorkerProcess())
>> + ereport(WARNING,
>> + (errmsg("skipping \"%s\" --- relation no longer exists",
>> + relation->relname)));
>> I like the use of WARNING here, but we could use as well a LOG to be
>> consistent when a lock obtention is skipped.
>
> It looks like the LOG statement is only emitted for autovacuum, so maybe
> we should keep this at WARNING for consistency with the permission checks
> below it.
I've left this as-is for now. I considered emitting this statement as a
LOG for autovacuum, but I'm not sure there is terribly much value in
having autovacuum explain that it is skipping a relation because it was
concurrently dropped. Perhaps this is something we should emit at a
DEBUG level. What do you think?
Nathan
Attachment | Content-Type | Size |
---|---|---|
vacuum_multiple_tables_v22.patch | application/octet-stream | 28.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Korotkov | 2017-09-27 16:51:23 | Re: Pluggable storage |
Previous Message | Robert Haas | 2017-09-27 15:59:13 | Re: Multicolumn hash indexes |