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 |
Date: | 2018-06-12 05:53:18 |
Message-ID: | 20180612055317.GD31779@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
smarter.
- 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.
Thoughts?
--
Michael
Attachment | Content-Type | Size |
---|---|---|
0001-Prevent-hard-failures-of-standbys-caused-by-recycled.patch | text/x-diff | 3.9 KB |
From | Date | Subject | |
---|---|---|---|
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 |