| From: | "tsunakawa(dot)takay(at)fujitsu(dot)com" <tsunakawa(dot)takay(at)fujitsu(dot)com> |
|---|---|
| To: | "osumi(dot)takamichi(at)fujitsu(dot)com" <osumi(dot)takamichi(at)fujitsu(dot)com>, 'Masahiko Sawada' <sawada(dot)mshk(at)gmail(dot)com> |
| Cc: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, "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-11-27 07:01:16 |
| Message-ID: | TYAPR01MB2990A26C52D614078480F28AFEF80@TYAPR01MB2990.jpnprd01.prod.outlook.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
From: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)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 seems that 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_*, are emitted. What's the good name? IIUC, "minimal" is named after the fact that the minimal amount of WAL necessary for crash recovery is generated. "norecovery" or "unrecoverable"?
Regards
Takayuki Tsunakawa
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alexander Korotkov | 2020-11-27 07:23:09 | Re: Improving spin-lock implementation on ARM. |
| Previous Message | Fujii Masao | 2020-11-27 06:56:52 | Re: Use standard SIGHUP and SIGTERM handlers in autoprewarm module |