| From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
|---|---|
| To: | "osumi(dot)takamichi(at)fujitsu(dot)com" <osumi(dot)takamichi(at)fujitsu(dot)com>, "tsunakawa(dot)takay(at)fujitsu(dot)com" <tsunakawa(dot)takay(at)fujitsu(dot)com>, 'Fujii Masao' <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
| Cc: | "ashutosh(dot)bapat(dot)oss(at)gmail(dot)com" <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Disable WAL logging to speed up data loading |
| Date: | 2020-10-28 20:32:07 |
| Message-ID: | 6a109368564942daeab6d4e93a56db8a14488de0.camel@cybertec.at |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, 2020-10-28 at 14:05 +0100, I wrote:
> 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.
Yours,
Laurenz Albe
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Fabrízio de Royes Mello | 2020-10-28 20:43:08 | Re: Add important info about ANALYZE after create Functional Index |
| Previous Message | Bruce Momjian | 2020-10-28 20:23:59 | Re: Internal key management system |