Re: [HACKERS] [Proposal] Allow users to specify multiple tables inVACUUM commands
От | Michael Paquier |
---|---|
Тема | Re: [HACKERS] [Proposal] Allow users to specify multiple tables inVACUUM commands |
Дата | |
Msg-id | CAB7nPqTB6gbsvGVw=S7ZCn3CaTsMj-=iwF=x2Lnvm0t407-qVA@mail.gmail.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
|
Список | pgsql-hackers |
On Thu, Sep 28, 2017 at 1:20 AM, Bossart, Nathan <bossartn@amazon.com> wrote: > 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? DEBUG would be fine as well for me. Now that your patch provides a RangeVar consistently for all code paths, the message could show up unconditionally. -- Michael -- 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 по дате отправления: