public inbox for [email protected]
help / color / mirror / Atom feedFrom: Postgress Cybrosys <[email protected]>
To: [email protected]
Subject: [PATCH] pg_prewarm: validate that first_block <= last_block
Date: Fri, 27 Mar 2026 11:02:10 +0530
Message-ID: <CAG+=MFWVYMvqDUVrZYBQ1TGLsUbEP5PxU0rK=0o_D5PY1ica1Q@mail.gmail.com> (raw)
Hi psql hackers,
While reviewing contrib/pg_prewarm/pg_prewarm.c, I noticed that
pg_prewarm() does not validate that first_block <= last_block after
both values are resolved. When a caller passes a reversed range such
as pg_prewarm('mytable', 'buffer', 'main', 100, 50), the function
silently returns 0 without any indication that the range was empty.
Both block numbers pass their individual bounds checks, so the caller
gets no feedback that anything went wrong.
The fix adds an explicit check after both endpoints are fully resolved
(including NULL defaults) and emits an ERROR message.
Reproduction:
CREATE TABLE t (id int);
INSERT INTO t SELECT generate_series(1, 10000);
-- Before patch: silently returns 0
SELECT pg_prewarm('t', 'buffer', 'main', 100, 50);
pg_prewarm
------------
0
(1 row)
-- After patch: raises a clear error
SELECT pg_prewarm('t', 'buffer', 'main', 100, 50);
ERROR: ending block number cannot be less than starting block number
The patch is attached. It touches only contrib/pg_prewarm/pg_prewarm.c
--
Thanks & Regards,
*Jhon k*
Postgres Specialist
Project & IT Department
Cybrosys Technologies
Mail
Mobile
WhatsApp
[email protected]
+91 8606827707
+91 8606827707
Attachments:
[text/x-patch] 0001-pg_prewarm-validate-that-first_block-last_block.patch (1.5K, 3-0001-pg_prewarm-validate-that-first_block-last_block.patch)
download | inline diff:
From 20f857a8a296b1200e477bfd9c15d6218ad363ad Mon Sep 17 00:00:00 2001
From: demo <[email protected]>
Date: Fri, 27 Mar 2026 10:56:14 +0530
Subject: [PATCH] pg_prewarm: validate that first_block <= last_block
pg_prewarm() accepted a block range where first_block > last_block
without complaint, silently returning 0 blocks prewarmed. Both block
numbers could individually pass their own range checks, yet the
resulting range is logically empty with no indication to the caller.
Add an explicit check after both first_block and last_block are fully
resolved (including NULL defaults) so that we can compare the two
finalized values and emit a clear error with errdetail showing the
exact values the caller supplied.
Reported-by: <[email protected]>
Author: <[email protected]>
---
contrib/pg_prewarm/pg_prewarm.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/contrib/pg_prewarm/pg_prewarm.c b/contrib/pg_prewarm/pg_prewarm.c
index c2716086693..b4d4a53dc84 100644
--- a/contrib/pg_prewarm/pg_prewarm.c
+++ b/contrib/pg_prewarm/pg_prewarm.c
@@ -189,6 +189,12 @@ pg_prewarm(PG_FUNCTION_ARGS)
errmsg("ending block number must be between 0 and %" PRId64,
(nblocks - 1))));
}
+ if (last_block < first_block)
+ {
+ ereport(ERROR,
+ (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
+ errmsg("ending block number cannot be less than starting block number")));
+ }
/* Now we're ready to do the real work. */
if (ptype == PREWARM_PREFETCH)
--
2.34.1
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected]
Subject: Re: [PATCH] pg_prewarm: validate that first_block <= last_block
In-Reply-To: <CAG+=MFWVYMvqDUVrZYBQ1TGLsUbEP5PxU0rK=0o_D5PY1ica1Q@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox