From: Michael Paquier [mailto:michael@paquier.xyz]
> Even with that, the resulting patch is sort of ugly... So it seems to me
> that the conclusion to this thread is that there is no clear winner, and
> that the problem is so unlikely to happen that it is not worth the performance
> impact to zero all the WAL pages fetched. Still, the attached has the
> advantage to not cause the startup process to fail suddendly because of
> the allocation failure but to fail afterwards when validating the record's
> contents, which has the disadvantage to allocate temporarily up to 1GB of
> memory for some of the garbage, but that allocation is short-lived. So
> that would switch the failure from a FATAL allocation failure taking down
> Postgres to something which will fetching of new WAL records to be tried
> again.
>
> All in all, that would be a win for the case reported on this thread.
I'm sorry to be late to reply, and thanks for another patch.
Honestly, I'm fine with either patch. I like your simpler and cleaner one that has no performance impact. But please
notethat the allocation attempt could amount to nearly 1 GB. That can fail due to memory shortage, which leads to
FATALerror (ereport(ERROR) results in FATAL in startup process), and cause standby to shut down.
Regards
Takayuki Tsunakawa
