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

From tsunakawa.takay@fujitsu.com
Subject RE: Disable WAL logging to speed up data loading
Date
Msg-id TYAPR01MB2990A26C52D614078480F28AFEF80@TYAPR01MB2990.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: Disable WAL logging to speed up data loading  (Masahiko Sawada <sawada.mshk@gmail.com>)
Responses Re: Disable WAL logging to speed up data loading  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
RE: Disable WAL logging to speed up data loading  ("osumi.takamichi@fujitsu.com" <osumi.takamichi@fujitsu.com>)
List pgsql-hackers
From: Masahiko Sawada <sawada.mshk@gmail.com>
> While testing the patch on some workload, I realized that
> XLOG_FPI_FOR_HINT record could still be emitted even when wal_level =
> none. IIUC that WAL record is not necessary during wal_level = none
> since the server cannot be the primary server and the server crash
> ends up requiring to restore the whole database.

Nice catch!  XLOG_FPI_FOR_HINT and XLOG_FPI should be eliminated, otherwise large amount of WAL may be written.  (It
seemsthat other RMIDs than RM_XLOG_ID and RM_XACT_ID do not have to be written.)
 

I'm afraid "none" doesn't represent the behavior because RM_XLOG_ID and RM_XACT_ID WAL records, except for XLOG_FPI_*,
areemitted.  What's the good name?  IIUC, "minimal" is named after the fact that the minimal amount of WAL necessary
forcrash recovery is generated.  "norecovery" or "unrecoverable"?
 

Regards
Takayuki Tsunakawa


pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: Use standard SIGHUP and SIGTERM handlers in autoprewarm module
Next
From: Alexander Korotkov
Date:
Subject: Re: Improving spin-lock implementation on ARM.