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 2CF97AEA-1F9B-49D6-8CF9-6260D2EE49AA@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  ("Bossart, Nathan" <bossartn@amazon.com>)
Список pgsql-hackers
On 9/28/17, 10:05 PM, "Bossart, Nathan" <bossartn@amazon.com> wrote:
> On 9/28/17, 8:46 PM, "Michael Paquier" <michael.paquier@gmail.com> wrote:
>> On Fri, Sep 29, 2017 at 10:44 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Michael Paquier <michael.paquier@gmail.com> writes:
>>>> On Fri, Sep 29, 2017 at 2:44 AM, Bossart, Nathan <bossartn@amazon.com> wrote:
>>>>> Alright, I've added logging for autovacuum in v23.  I ended up needing to
>>>>> do a little restructuring to handle the case when the relation was skipped
>>>>> because the lock could not be obtained.  While doing so, I became
>>>>> convinced that LOG was probably the right level for autovacuum logs.
>>>
>>>> OK, of course let's not change the existing log levels. This could be
>>>> always tuned later on depending on feedback from others. I can see
>>>> that guc.c also uses elevel == 0 for some logic, so we could rely on
>>>> that as you do.
>>>
>>> FWIW, I don't think this patch should be mucking with logging behavior
>>> at all; that's not within its headline charter, and I doubt many people
>>> are paying attention.  I propose to commit it without that.  If you feel
>>> hot about changing the logging behavior, you can resubmit that as a new
>>> patch in a new thread where it will get some visibility and debate on
>>> its own merits.
>>
>> Okay. I am fine with that as well.
>
> Sure, that seems reasonable to me.

Here's a version without the logging changes in vacuum_rel() and
analyze_rel().  I’ll look into submitting those in the next commitfest.

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] The case for removing replacement selection sort
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] Multicolumn hash indexes