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

From osumi.takamichi@fujitsu.com
Subject RE: Disable WAL logging to speed up data loading
Date
Msg-id OSBPR01MB48885361D758639102DCED7BED170@OSBPR01MB4888.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: Disable WAL logging to speed up data loading  (Laurenz Albe <laurenz.albe@cybertec.at>)
Responses Re: Disable WAL logging to speed up data loading
List pgsql-hackers
Hi, Laurenz


> > I wrote and attached the first patch to disable WAL logging.
> > This patch passes the regression test of check-world already and is
> > formatted by pgindent.
> 
> Without reading the code, I have my doubts about that feature.
> 
> While it clearly will improve performance, it opens the door to data loss.
Therefore, this feature must avoid that
that kind of inconsistent server starts up again.
This has been discussed in this thread already.

> People will use it to speed up their data loads and then be unhappy if they
> cannot use their backups to recover from a problem.
> 
> What happens if you try to do archive recovery across a time where wal_level
> was "none"?  Will the recovery process fail, as it should, or will you end up
> with data corruption?
> 
> We already have a performance-related footgun in the shape of fsync = off.
> Do we want to add another one?
Further, in this thread, we discuss that 
this feature is intended to serve under
some specific opportunities like DBA wants
to load data as soon as possible and/or the operation itself is easily *repeatable*.
So, before and after the change of wal_level, DBA needs to take a full backup to
prepare the unexpected crash.

But anyway, I'll fix and enrich the documents. Thanks.

Best,
    Takamichi Osumi

pgsql-hackers by date:

Previous
From: Oleksandr Shulgin
Date:
Subject: Re: cutting down the TODO list thread
Next
From: Masahiko Sawada
Date:
Subject: Re: shared tempfile was not removed on statement_timeout