|From:||"Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>|
|To:||'Michael Paquier' <michael(at)paquier(dot)xyz>|
|Cc:||Postgres hackers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||RE: [bug fix] Cascaded standby cannot start after a clean shutdown|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
From: Michael Paquier [mailto:michael(at)paquier(dot)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
> 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.
|Next Message||Pavan Deolasee||2018-03-16 05:39:07||Re: [HACKERS] MERGE SQL Statement for PG11|
|Previous Message||Michael Paquier||2018-03-16 05:23:54||Re: Problem while setting the fpw with SIGHUP|