From: Michael Paquier [mailto:mich...@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 note that the allocation attempt could amount to nearly 1 GB. That can fail due to memory shortage, which leads to FATAL error (ereport(ERROR) results in FATAL in startup process), and cause standby to shut down. Regards Takayuki Tsunakawa
