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

From Kyotaro Horiguchi
Subject Re: Disable WAL logging to speed up data loading
Date
Msg-id 20201002.140752.958558461530383405.horikyota.ntt@gmail.com
Whole thread Raw
In response to Re: Disable WAL logging to speed up data loading  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
List pgsql-hackers
At Fri, 02 Oct 2020 13:51:35 +0900 (JST), Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote in 
> Sorry for the slippery brain...  ^2

> At Fri, 02 Oct 2020 13:38:22 +0900 (JST), Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote in 
> > At Fri, 2 Oct 2020 10:56:21 +0900, Fujii Masao <masao.fujii@oss.nttdata.com> wrote in 
> > > 
> > > On 2020/10/02 10:06, Kyotaro Horiguchi wrote:
> > > > 1. Flip BM_PERMANENT of active buffers
> > > > 2. adding/removing init fork
> > > > 3. sync files,
> > > > 4. Flip pg_class.relpersistence.
> > > > It always skips table copy in the SET UNLOGGED case,
> > > 
> > > Even in wal_level != minimal?
> > > What happens in the standby side when SET UNLOGGED is executed without
> > > the table rewrite in the primary? The table data should be truncated
> > > in the standby?
> > 
> > A table turned into unlogged on the primary is also turned into
> > unlogged on the standby and it is inaccessible on the standby.

> Maybe the storage dropped on unpatched

Maybe the old storage is replaced with an empty stroage on unpatched.

> and left alone on patched.

> > After the table is again turned into logged, the content is
> > transferred via WAL records generated from the insertions into the new
> > storage and it rebuilds the same storage on the standby on both
> > patched and unpatched.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



pgsql-hackers by date:

Previous
From: "tsunakawa.takay@fujitsu.com"
Date:
Subject: RE: Disable WAL logging to speed up data loading
Next
From: "Drouvot, Bertrand"
Date:
Subject: Re: Add information to rm_redo_error_callback()