|From:||Michael Paquier <michael(at)paquier(dot)xyz>|
|To:||"Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>|
|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|
On Sun, Mar 18, 2018 at 08:49:01AM +0900, Michael Paquier wrote:
> On Fri, Mar 16, 2018 at 06:02:25AM +0000, Tsunakawa, Takayuki wrote:
>> Ouch, you're right. If memory allocation fails, the startup process
>> would emit a LOG message and continue to fetch new WAL records. Then,
>> I'm completely happy with your patch.
> Thanks for double-checking, Tsunakawa-san.
As this is one of those small bug fixes for which we can do something,
attached is an updated patch with a commit description, and
tutti-quanti. At the end, I have moved the size check within
allocate_recordbuf(). Even if the size calculated is not going to be
higher than total_len, it feels safer in the long term for two reasons:
- Allocation size calculation could be changed, or let's say made
- New callers of allocate_recordbuf would not be able to see the problem
for the backend, and this could become a problem if the WAL reader
facility is extended.
|Next Message||Tsunakawa, Takayuki||2018-06-12 06:30:49||RE: [bug fix] Cascaded standby cannot start after a clean shutdown|
|Previous Message||Michael Paquier||2018-06-12 04:49:26||Re: SCRAM with channel binding downgrade attack|