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 OSBPR01MB488832B36D4939ADEBA9E425ED140@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  (Laurenz Albe <laurenz.albe@cybertec.at>)
List pgsql-hackers
Hello


> > But what if someone sets wal_level=none, performs some data
> > modifications, sets wal_level=archive and after dome more processing
> > decides to restore from a backup that was taken before the cluster was set
> to wal_level=none?
> > Then they would end up with a corrupted database, right?
> >
> > I think the least this patch needs is that starting with
> > wal_level=none emits a WAL record that will make recovery fail.
> 
> I just realized that changing "wal_level" will cause a WAL record anyway.
> Besides, the situation is not much different from changing to "wal_level =
> minimal".
> So as long as PostgreSQL refuses to start after a crash, we should be good.
> 
> Sorry for the noise, and I am beginning to think that this is actually a useful
> feature.
No problem at all.
Probably, for some developers, was the name "none" confusing ?

Also, thank you for your pointing out my lack of explanation
in the documents of the replication in the previous e-mail.


Best,
    Takamichi Osumi

pgsql-hackers by date:

Previous
From: "Shinoda, Noriyoshi (PN Japan A&PS Delivery)"
Date:
Subject: RE: Online checksums verification in the backend
Next
From: Julien Rouhaud
Date:
Subject: Re: Online checksums verification in the backend