Re: O(n) tasks cause lengthy startups and checkpoints

Поиск
Список
Период
Сортировка
От Bossart, Nathan
Тема Re: O(n) tasks cause lengthy startups and checkpoints
Дата
Msg-id A285A823-0AF2-4376-838E-847FA4710F9A@amazon.com
обсуждение исходный текст
Ответ на Re: O(n) tasks cause lengthy startups and checkpoints  (Andres Freund <andres@anarazel.de>)
Ответы Re: O(n) tasks cause lengthy startups and checkpoints  ("Euler Taveira" <euler@eulerto.com>)
Список pgsql-hackers
On 12/1/21, 2:56 PM, "Andres Freund" <andres@anarazel.de> wrote:
> On 2021-12-01 20:24:25 +0000, Bossart, Nathan wrote:
>> I realize adding a new maintenance worker might be a bit heavy-handed,
>> but I think it would be nice to have somewhere to offload tasks that
>> really shouldn't impact startup and checkpointing.  I imagine such a
>> process would come in handy down the road, too.  WDYT?
>
> -1. I think the overhead of an additional worker is disproportional here. And
> there's simplicity benefits in having a predictable cleanup interlock as well.

Another idea I had was to put some upper limit on how much time is
spent on such tasks.  For example, a checkpoint would only spend X
minutes on CheckPointSnapBuild() before giving up until the next one.
I think the main downside of that approach is that it could lead to
unbounded growth, so perhaps we would limit (or even skip) such tasks
only for end-of-recovery and shutdown checkpoints.  Perhaps the
startup tasks could be limited in a similar fashion.

> I think particularly for the snapshot stuff it'd be better to optimize away
> unnecessary snapshot files, rather than making the cleanup more asynchronous.

I can look into this.  Any pointers would be much appreciated.

Nathan


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

Предыдущее
От: Paul Martinez
Дата:
Сообщение: Re: [PATCH] Partial foreign key updates in referential integrity triggers
Следующее
От: "Bossart, Nathan"
Дата:
Сообщение: Re: Postgres restart in the middle of exclusive backup and the presence of backup_label file