| 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-02-27 05:15:29 |
| Message-ID: | 0A3221C70F24FB45833433255569204D1F8D7667@G01JPEXMBYT05 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
From: Michael Paquier [mailto:michael(at)paquier(dot)xyz]
> By the way, as long as I have my mind of it. Another strategy would be
> to just make the checks in XLogReadRecord() a bit smarter if the whole record
> header is not on the page. If we check at least for
> AllocSizeIsValid(total_len) then there this code would not fail on an
> allocation as you user reported. Still this misses the case where a record
> size is lower than 1GB but invalid so you would allocate allocate_recordbuf
> for nothing :(
That was my first thought, and I gave it up. As you say, XLogReadRecord() could allocate up to 1 GB of memory for a garbage. That allocation can fail due to memory shortage, which prevents the recovery from proceeding.
Regards
Takayuki Tsunakawa
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2018-02-27 05:21:00 | Re: Kerberos test suite |
| Previous Message | Andrew Dunstan | 2018-02-27 03:59:44 | Re: ALTER TABLE ADD COLUMN fast default |