Re: PATCH: standby crashed when replay block which truncated instandby but failed to truncate in master node
| От | Fujii Masao |
|---|---|
| Тема | Re: PATCH: standby crashed when replay block which truncated instandby but failed to truncate in master node |
| Дата | |
| Msg-id | 85e6a369-8e63-1b8d-6a88-14cd0a467667@oss.nttdata.com обсуждение исходный текст |
| Ответ на | Re: PATCH: standby crashed when replay block which truncated instandby but failed to truncate in master node (Michael Paquier <michael@paquier.xyz>) |
| Список | pgsql-hackers |
On 2020/01/18 12:48, Michael Paquier wrote: > On Fri, Jan 17, 2020 at 07:36:51PM +0900, Fujii Masao wrote: >> On Fri, Jan 17, 2020 at 1:47 PM Michael Paquier <michael@paquier.xyz> wrote: >>> Thanks. I have few tweaks to propose to the docs. >>> >>> + raise a PANIC-level error, aborting the recovery. Setting >>> Instead of "PANIC-level error", I would just use "PANIC error", and >> >> I have no strong opinion about this, but I used "PANIC-level error" >> because the description for data_sync_retry has already used it. > > Okay. Fine with what you think is good. > >>> instead of "aborting the recovery" just "crashing the server". >> >> PANIC implies server crash, so IMO "crashing the server" is >> a bit redundant, and "aborting the recovery" is better because >> "continue the recovery" is used later. > > Okay. I see your point here. > >> So, what about >> >> --------------- >> causes the system to ignore invalid page references in WAL records >> (but still report a warning), and continue the recovery. >> --------------- > > And that sounds good to me. Switching the patch as ready for > committer. Thanks! Committed! Regards, -- Fujii Masao NTT DATA CORPORATION Advanced Platform Technology Group Research and Development Headquarters
В списке pgsql-hackers по дате отправления: