Re: [HACKERS] [Proposal] Allow users to specify multiple tables inVACUUM commands

Поиск
Список
Период
Сортировка
От Bossart, Nathan
Тема Re: [HACKERS] [Proposal] Allow users to specify multiple tables inVACUUM commands
Дата
Msg-id FABB745C-F6F8-436B-9872-6C1495A8137E@amazon.com
обсуждение исходный текст
Ответ на Re: [HACKERS] [Proposal] Allow users to specify multiple tables inVACUUM commands  ("Bossart, Nathan" <bossartn@amazon.com>)
Ответы Re: [HACKERS] [Proposal] Allow users to specify multiple tables inVACUUM commands  (Michael Paquier <michael.paquier@gmail.com>)
Список 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@amazon.com> wrote:
> On 9/25/17, 12:42 AM, "Michael Paquier" <michael.paquier@gmail.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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] Multicolumn hash indexes
Следующее
От: Alexander Korotkov
Дата:
Сообщение: Re: [HACKERS] Pluggable storage