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 |
Date: | 2018-03-16 05:27:58 |
Message-ID: | 0A3221C70F24FB45833433255569204D1F903D56@G01JPEXMBYT05 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
> 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
From | Date | Subject | |
---|---|---|---|
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 |