Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints
Date: 2022-02-11 21:08:31
Message-ID: 202202112108.mmy2r4g7zj7o@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2022-Feb-11, Robert Haas wrote:

> What I find difficult about doing that is that this is all a bunch of
> technical details that users may have difficulty understanding. If we
> say WAL_LOG or WAL_LOG_DATA, a reasonably but not incredibly
> well-informed user will assume that skipping WAL is not really an
> option. If we say CHECKPOINT, a reasonably but not incredibly
> well-informed user will presume they don't want one (I think).
> CHECKPOINT also seems like it's naming the switch by the unwanted side
> effect, which doesn't seem too flattering to the existing method.

It seems you're thinking deciding what to do based on an option that
gets a boolean argument. But what about making the argument be an enum?
For example

CREATE DATABASE ... WITH (STRATEGY = LOG); -- default if option is omitted
CREATE DATABASE ... WITH (STRATEGY = CHECKPOINT);

So the user has to think about it in terms of some strategy to choose,
rather than enabling or disabling some flag with nontrivial
implications.

--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"[PostgreSQL] is a great group; in my opinion it is THE best open source
development communities in existence anywhere." (Lamar Owen)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2022-02-11 21:11:18 Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints
Previous Message Robert Haas 2022-02-11 21:05:04 Re: Per-table storage parameters for TableAM/IndexAM extensions