From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Christoph Berg <myon(at)debian(dot)org> |
Cc: | Nathan Bossart <nathandbossart(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: CHECKPOINT unlogged data |
Date: | 2025-05-30 17:29:08 |
Message-ID: | 7x6gsmev36zzh6lfzydkddbhpnxqgu2k2l2ci2k6foxhrstvj2@bn55g54wjrl4 |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2025-05-30 19:23:04 +0200, Christoph Berg wrote:
> Re: Nathan Bossart
> > This patch also adds an IMMEDIATE option, which I proposed some time ago
> > [0]. I ended up withdrawing it due to general skepticism about its
>
> Thanks for the pointer, I did not go that far back when looking for
> older threads.
>
> When writing the patch, I was also thinking about naming the option
> "fast" or "spread" but ultimately went with "immediate" because that's
> what the log message is using:
>
> =# checkpoint;
> 2025-05-30 18:23:17.433 CEST [579834] LOG: Checkpoint beginnt: immediate force wait
>
> SQL command "(options)" tend to be booleans, hence "immediate {on|off}".
> Introducing two separate keywords "fast" and "spread" seemed
> confusing, and there is no precedent for "fast=on" in other tools or
> the replication protocol.
I'd add a 'mode' that can be set to an arbitrary string, which then can be
validated in C code. That seems more future proof.
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Bossart | 2025-05-30 18:17:46 | Re: regdatabase |
Previous Message | Christoph Berg | 2025-05-30 17:23:04 | Re: CHECKPOINT unlogged data |