Tom Lane-2 wrote
> Tomas Vondra <
> tv@
> > writes:
>> So maybe we shouldn't cling to the WAL-logging approach too much. Maybe
>> Heikki's idea from to abandon the full checkpoint and instead assume
>> that once the transaction commits, all the files were fsynced OK. Of
>> couse, this will do nothing about the replay hazards.
>
> Well, I'm not insisting on any particular method of getting there, but
> if we're going to touch this area at all then I think "fix the replay
> hazards" should be a non-negotiable requirement. We'd never have accepted
> such hazards if CREATE DATABASE were being introduced for the first time;
> it's only like this because nobody felt like rewriting a Berkeley-era
> kluge.
Maybe adding a ToDo:
"Fix replay hazards in CREATE DATABASE"
and listing them explicitly would be a good start.
Not sure if WAL or CREATE would be more appropriate but WAL seems like a
better fit.
To the topic at hand would "CREATE DATABASE name WITH LOGGED = true" work?
As with UNLOGGED tables giving the user the choice of WAL/fsync/checkpoint
behavior seems reasonable. As Thomas said there a couple of diametrically
opposed use-cases here and it seems like we've already implemented the more
difficult one.
Addressing the reply hazards in the existing implementation could be
considered separately. What I'm not sure is whether the logging version in
fact already addresses them and in the interest of safe and sane defaults
whether we should implement and make it default and have the user specify
logged = false to get the old behavior with warnings emitted as to the
replay hazards that could occur should the database crash during the create.
Is it possible to emit a warning before the command completes (or, rather,
begins)?
David J.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/proposal-CREATE-DATABASE-vs-partial-CHECKPOINT-tp5824343p5824526.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.