| From: | "tsunakawa(dot)takay(at)fujitsu(dot)com" <tsunakawa(dot)takay(at)fujitsu(dot)com> |
|---|---|
| To: | 'Michael Paquier' <michael(at)paquier(dot)xyz> |
| 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 01:00:41 |
| Message-ID: | TYAPR01MB2990ED81C3BBDC5054AAE19BFE310@TYAPR01MB2990.jpnprd01.prod.outlook.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
From: Michael Paquier <michael(at)paquier(dot)xyz>
> 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.
Maybe, although I'm not sure lseek() is necessary. I simply thought walsender was designed to just read and send WAL without caring about other things for maximal speed.
> 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.
Yes, I think cold archives should be checked regularly. pg_verifybackup and pg_waldump can be used for it, can't they?
Regards
Takayuki Tsunakawa
| From | Date | Subject | |
|---|---|---|---|
| Next Message | tsunakawa.takay@fujitsu.com | 2020-10-02 01:05:44 | RE: New statistics for tuning WAL buffer size |
| Previous Message | Michael Paquier | 2020-10-02 00:47:29 | Re: Add information to rm_redo_error_callback() |