Re: Should vacuum process config file reload more often

Поиск
Список
Период
Сортировка
От Daniel Gustafsson
Тема Re: Should vacuum process config file reload more often
Дата
Msg-id 2B703533-102A-47E5-A4F7-C6A68C09BB27@yesql.se
обсуждение исходный текст
Ответ на Re: Should vacuum process config file reload more often  (Melanie Plageman <melanieplageman@gmail.com>)
Ответы Re: Should vacuum process config file reload more often  (Masahiko Sawada <sawada.mshk@gmail.com>)
Re: Should vacuum process config file reload more often  (John Naylor <john.naylor@enterprisedb.com>)
Список pgsql-hackers
> On 7 Apr 2023, at 00:12, Melanie Plageman <melanieplageman@gmail.com> wrote:
>
> On Thu, Apr 6, 2023 at 5:45 PM Daniel Gustafsson <daniel@yesql.se> wrote:
>>
>>> On 6 Apr 2023, at 23:06, Melanie Plageman <melanieplageman@gmail.com> wrote:
>>
>>> Autovacuum workers, at the end of VacuumUpdateCosts(), check if cost
>>> limit or cost delay have been changed. If they have, they assert that
>>> they don't already hold the AutovacuumLock, take it in shared mode, and
>>> do the logging.
>>
>> Another idea would be to copy the values to local temp variables while holding
>> the lock, and release the lock before calling elog() to avoid holding the lock
>> over potential IO.
>
> Good idea. I've done this in attached v19.
> Also I looked through the docs and everything still looks correct for
> balancing algo.

I had another read-through and test-through of this version, and have applied
it with some minor changes to comments and whitespace.  Thanks for the quick
turnaround times on reviews in this thread!

I opted for keeping the three individual commits, squashing them didn't seem
helpful enough to future commitlog readers and no other combination of the
three made more sense than what has been in the thread.

--
Daniel Gustafsson




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

Предыдущее
От: Thomas Munro
Дата:
Сообщение: Re: Using each rel as both outer and inner for JOIN_ANTI
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Non-replayable WAL records through overflows and >MaxAllocSize lengths