| From: | Hannu Krosing <hannuk(at)google(dot)com> |
|---|---|
| To: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> |
| Cc: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Thomas wen <Thomas_valentine_365(at)outlook(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Peter Geoghegan <pg(at)bowt(dot)ie> |
| Subject: | Re: incremental-checkopints |
| Date: | 2023-07-26 20:56:45 |
| Message-ID: | CAMT0RQTtMCc4UGrLniPeiKnqydRH1UAM+9WOz+DcOkD8O+EctQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Jul 26, 2023 at 9:54 PM Matthias van de Meent
<boekewurm+postgres(at)gmail(dot)com> wrote:
>
> Then you ignore the max_wal_size GUC as PostgreSQL so often already
> does. At least, it doesn't do what I expect it to do at face value -
> limit the size of the WAL directory to the given size.
That would require stopping any new writes at wal size == max_wal_size
until the checkpoint is completed.
I don't think anybody would want that.
> But more reasonably, you'd keep track of the count of modified pages
> that are yet to be fully WAL-logged, and keep that into account as a
> debt that you have to the current WAL insert pointer when considering
> checkpoint distances and max_wal_size.
I think Peter Geoghegan has worked on somewhat similar approach to
account for "accumulated work needed until some desired outcome"
though I think it was on the VACUUM side of things.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2023-07-26 21:14:08 | Re: Obsolete reference to pg_relation in comment |
| Previous Message | Nathan Bossart | 2023-07-26 20:50:31 | Re: Obsolete reference to pg_relation in comment |