Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints - Mailing list pgsql-hackers

From Dilip Kumar
Subject Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints
Date
Msg-id CAFiTN-vDM2ShwE-5e4gu_H8Cp8MQwURk+n=21+wX_QzkDi8-Bg@mail.gmail.com
Whole thread Raw
In response to Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints  (Dilip Kumar <dilipbalaut@gmail.com>)
Responses Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Sun, Feb 13, 2022 at 10:12 AM Dilip Kumar <dilipbalaut@gmail.com> wrote:
>
> On Sat, Feb 12, 2022 at 2:38 AM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:

> > 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.
>
>
> Yeah I think being explicit about giving the strategy to the user
> looks like a better option.  Now they can choose whether they want it
> to create using WAL log or using CHECKPOINT.  Otherwise, if we give a
> flag then we will have to give an explanation that if they choose not
> to WAL log then we will have to do a checkpoint internally.  So I
> think giving LOG vs CHECKPOINT as an explicit option looks better to
> me.

So do we have consensus to use (STRATEGY = LOG/CHECKPOINT or do we
think that keeping it bool i.e. Is LOG_COPIED_BLOCKS a better option?
Once we have consensus on this I will make this change and
documentation as well along with the other changes suggested by
Robert.

-- 
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Dagfinn Ilmari Mannsåker
Date:
Subject: Re: bailing out in tap tests nearly always a bad idea
Next
From: Robert Haas
Date:
Subject: Re: Mark all GUC variable as PGDLLIMPORT