| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> |
| Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, David Zhang <david(dot)zhang(at)highgo(dot)ca>, Andres Freund <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Non-replayable WAL records through overflows and >MaxAllocSize lengths |
| Date: | 2022-07-27 09:09:38 |
| Message-ID: | YuEA0ootBIJVlLhg@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Jul 26, 2022 at 06:58:02PM +0200, Matthias van de Meent wrote:
> - Retained the check in XLogRegisterData, so that we check against
> integer overflows in the registerdata code instead of only an assert
> in XLogRecordAssemble where it might be too late.
Why? The record has not been inserted yet. I would tend to keep only
the check at the bottom of XLogRecordAssemble(), for simplicity, and
call it a day.
> - Kept the inline static elog-ing function (as per Andres' suggestion
> on 2022-03-14; this decreases binary sizes)
I am not really convinced that this one is worth doing.
+#define MaxXLogRecordSize (1020 * 1024 * 1024)
+
+#define XLogRecordLengthIsValid(len) ((len) >= 0 && (len) < MaxXLogRecordSize)
These are used only in xloginsert.c, so we could keep them isolated.
+ * To accommodate some overhead, hhis MaxXLogRecordSize value allows for
s/hhis/this/.
For now, I have extracted from the patch the two API changes and the
checks for the block information for uint16, and applied this part.
That's one less thing to worry about.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Xing Guo | 2022-07-27 09:09:54 | [PATCH] Simple code cleanup in tuplesort.c. |
| Previous Message | Matthias van de Meent | 2022-07-27 08:30:18 | Re: [PATCH] Compression dictionaries for JSONB |