Re: Disable WAL logging to speed up data loading - Mailing list pgsql-hackers

On Fri, 2021-03-19 at 06:53 +0000, tsunakawa.takay@fujitsu.com wrote:
> From: David Steele <david@pgmasters.net>
> > After reading through the thread (but not reading the patch) I am -1 on
> > this proposal.
> > 
> > The feature seems ripe for abuse and misunderstanding, and as has been
> > noted in the thread, there are a variety of alternatives that can
> > provide a similar effect.
> > 
> > It doesn't help that at several points along the way new WAL records
> > have been found that still need to be included even when wal_level =
> > none. It's not clear to me how we know when we have found them all.
> > 
> > The patch is marked Ready for Committer but as far as I can see there
> > are no committers in favor of it and quite a few who are not.
> 
> I can understand that people are worried about not having WAL.  But as far
>  as I remember, I'm afraid those concerns were emotional, not logical,
>  i.e., something like "something may happen.".  Regarding concrete concerns
>  that Stephen-san, Magnus-san, Horiguchi-san, Sawada-san and others raised,
>  Osumi-san addressed them based on their advice and review, both in this
>  thread and other threads.
> 
> I also understand we want to value people's emotion for worry-free PostgreSQL.
> At the same time, I'd like the emotion understood that we want Postgres to
>  have this convenient, easy-to-use feature.  MySQL recently introduced this
>  feature.  Why can't Postgres do it?

Part of what gives PostgreSQL the good name it has is that we strive to
make it very hard to mess up your data.  We are finicky about encoding
correctness, we don't allow you to drop a table used by a view, and so on.

All these things are annoying to users, but we'd rather take that than
the complaints that a database got corrupted because somebody didn't read
the documentation carefully.

Now I'm not saying that this feature should not go in (I set it to
"ready for committer", because I see no technical flaw with the
implementation), but it remains debatable if we want the feature or not.

I certainly can see David's point of view.  And we don't view MySQL as
a role model that we want to emulate.

> > Perhaps it would be better to look at some of the more targeted
> > approaches mentioned in the thread and see if any of them can be
> > used/improved to achieve the desired result?
> 
> Other methods are not as easy-to-use, and more complex to implement.

Fast and loose often takes less effort, yes.

Yours,
Laurenz Albe