Re: PATCH: standby crashed when replay block which truncated in standby but failed to truncate in master node
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Fujii Masao <masao.fujii@gmail.com>
Cc: Tomas Vondra <tomas.vondra@2ndquadrant.com>, Thunder <thunder1@126.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-12-17T05:19:13Z
Lists: pgsql-hackers
On Mon, Dec 16, 2019 at 12:22:18PM +0900, Fujii Masao wrote: > > + Detection of WAL records having references to invalid pages during > > + recovery causes <productname>PostgreSQL</productname> to report > > + an error, aborting the recovery. Setting > > Well, that's not really an error. This triggers a PANIC, aka crashes > > the server. And in this case the actual problem is that you may not > > be able to move on with recovery when restarting the server again, > > except if luck is on your side because you would continuously face > > it.. > > So you're thinking that "report an error" should be changed to > "trigger a PANIC"? Personally "report an error" sounds ok because > PANIC is one of "error", I think. But if that misleads people, > I will change the sentence. In the context of a recovery, an ERROR is promoted to a FATAL, but here are talking about something that bypasses the crash of the server. So this could bring confusion. I think that the documentation should be crystal clear about that, with two aspects outlined when the parameter is disabled, somewhat like data_sync_retry actually: - A PANIC-level error is triggered. - It crashes the cluster. -- Michael
Commits
-
Add GUC ignore_invalid_pages.
- 41c184bc642b 13.0 landed