From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | "tsunakawa(dot)takay(at)fujitsu(dot)com" <tsunakawa(dot)takay(at)fujitsu(dot)com> |
Cc: | 'Konstantin Knizhnik' <k(dot)knizhnik(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Should walsernder check correctness of WAL records? |
Date: | 2020-10-02 00:28:53 |
Message-ID: | 20201002002853.GB1464@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Oct 02, 2020 at 12:16:25AM +0000, tsunakawa(dot)takay(at)fujitsu(dot)com wrote:
> IIUC, walsender tries hard to send WAL as fast as possible to reduce
> replication lag and transaction response time, so it doesn't try to
> peek each WAL record. I think it's good.
CRC calculation would unlikely be the bottleneck here, no? I would
assume that the extra lseek() calls needed to look after the record
data to be more harmful.
> In any case, the WAL can get corrupt during transmission, and
> writing and reading on the standby. So, the standby needs to check
> the WAL record CRC.
Yep. However, I would worry much more about the case of cold
archives. In my experience, there are higher risks to get a WAL
segment corrupted because it was on disk and that this disk got
corrupted. Transmission is a one-time short operation. Cold archives
could stay on disk for weeks before getting reused in WAL replay.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2020-10-02 00:38:07 | Re: New statistics for tuning WAL buffer size |
Previous Message | tsunakawa.takay@fujitsu.com | 2020-10-02 00:16:25 | RE: Should walsernder check correctness of WAL records? |