Re: O(n) tasks cause lengthy startups and checkpoints - Mailing list pgsql-hackers

From Bossart, Nathan
Subject Re: O(n) tasks cause lengthy startups and checkpoints
Date
Msg-id A285A823-0AF2-4376-838E-847FA4710F9A@amazon.com
Whole thread Raw
In response to Re: O(n) tasks cause lengthy startups and checkpoints  (Andres Freund <andres@anarazel.de>)
Responses Re: O(n) tasks cause lengthy startups and checkpoints
List 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 by date:

Previous
From: Paul Martinez
Date:
Subject: Re: [PATCH] Partial foreign key updates in referential integrity triggers
Next
From: "Bossart, Nathan"
Date:
Subject: Re: Postgres restart in the middle of exclusive backup and the presence of backup_label file