Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1w5zo5-003q7s-0W for pgsql-hackers@arkaria.postgresql.org; Fri, 27 Mar 2026 05:32:29 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w5zo3-007gZk-0W for pgsql-hackers@arkaria.postgresql.org; Fri, 27 Mar 2026 05:32:27 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1w5zo2-007gZc-2Q for pgsql-hackers@lists.postgresql.org; Fri, 27 Mar 2026 05:32:27 +0000 Received: from mail-ed1-x534.google.com ([2a00:1450:4864:20::534]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1w5zo0-00000001Q6l-1Mjh for pgsql-hackers@lists.postgresql.org; Fri, 27 Mar 2026 05:32:26 +0000 Received: by mail-ed1-x534.google.com with SMTP id 4fb4d7f45d1cf-667de793310so2927798a12.0 for ; Thu, 26 Mar 2026 22:32:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1774589543; cv=none; d=google.com; s=arc-20240605; b=lkh81wBC6NGCor7upjHAqKQ3H1awvpGctV043yb3UUSb9c5sTzKa8uei0PawHZ6VBV j34IhrbUDKpXKd2sYSLCKJUszQQPwl613CiPeDVRocWinyG9aGSNzzLgrPJAl05WWC7A +D2bPa3kfKpcg8uw6+JyLlgvJGpGi655CztfMWBKsqQPEe+5ir4tzb1gqVSEUfOAwUSv Tan0UM5d/N18NpH5DCikcq8uOkMBsjA7lUpf4rLU36FslBCAvnwoMntYzCX4OmsrD+S3 MqIpLCSb8+3WHjHhg0Ig1xcA9Yul87U9dQBayqxJrmieyWaEhTl6dVVf7+G3KvN/WUJp CLBg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=to:subject:message-id:date:from:mime-version:dkim-signature; bh=HEe+rM1kyfncYhL0RQdBhcgHBLZzjYyjb0DwnED65WI=; fh=nwNxTtLLPTU0ewfLM7SSbrjMajMl+wwnFkCY/fi90vE=; b=RWL2GQiLD/+4dSkG2fuUYnvS10pysqbP50Wsb8cbeZ5uPECcMvuB1iM+xl226FLF6K qjfc9iyFxclLFh/7Hap3S23LGSC3rsVUh1OyKqNfihQN/+EhFYFDThaQvrfnWi8wlsN5 Ikd8Cpo+BLuyUo6RtzDowkUaxURJlOCUwgqpiss17shSnUJEOEYxX9pHbjtSDNIR2U4Y 7xkdm94j0HcURkHpC6MmdT+oDgGYVx8GWJesgKpSuXl+zNc9Wo4i7owSz2oYlEhDuFtq kS1oHpNlKk7jflegTs8LHwVnjwCPeUVjMrQRGK2j+5KRT+2lQl6ClkAzTpyKqjvPORUL 09Zg==; darn=lists.postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybrosys-com.20230601.gappssmtp.com; s=20230601; t=1774589543; x=1775194343; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=HEe+rM1kyfncYhL0RQdBhcgHBLZzjYyjb0DwnED65WI=; b=QgkOGhJcXFNhhdmdLqTrtto5RrmABLe+4qQmn6Gvxq8NhpfXDg8UqDEMn0YITfSYBW jBX3KER9G2oVeYpYPfFgY1gbOpJswGR9U7jsau2pCIPjHAP6+6tcLYnS6BfnoS0PFGOh g38K1ygjUZ4XH5aaXFmQEDRJeyyJBczXOcMyLU2MS2xNi1uXfFEsfUEA6sScjnt+vOxb NnUqib8Oh6BVfBEJ0i1eiDGb78g456JSLxEoSk4k2PfSeLFKTmaTi2L0tlNT0/+pmtk9 7PsVj0UepAnyqUhAnkRLHg4f58ffnNJbCPgQYY6JdOJPJrzrej62ge/Eq9HyckxSiJgN ++YQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774589543; x=1775194343; h=to:subject:message-id:date:from:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=HEe+rM1kyfncYhL0RQdBhcgHBLZzjYyjb0DwnED65WI=; b=V9jUqai1telhe7/kt+Z2U2A4RN0LPjJrDwWV/wYCkybMMpeQZnkQATsFYw8n+ou5fE 6bUIlo9FVjWpeJVgUPfvVc+NT8fq0elduTkIOzRzDvUAtHrt+GNd+67uNlcy3KEN5lC8 xjwbrLn9GOn2wV1X28nYtiPx1E+i1aXhK4g9jcuvs0cHLKjKY4ikfE5zqwizrcD40F3W LnKlPNA2f3OMR/yAp7HcdycBKz+xQintDOL+XyHMrr3PaFvmA7Q4y7sD07zQWbMVzSp4 13fEL9atHz4bqN7ui/SEoYI9gIQtRc20G81jscLePxmAuRlj0zmjRgiWsGP0nt9Wht/r mOYw== X-Gm-Message-State: AOJu0YxlNwZnIu6MJLd+jIGDv5wEgAv1xhfisd/rxjPpMryxgujqAOoC 4SH8VcHqrTkYe80tjBauah11nCyjFKjdDqq5w1bgavZE3YKumtaWTfCQ7/s8b+jJEGkUXhEJnGr cNOjfqdD0q1031qRBFZaXJT12co6hbX8dkxSGNjxxlCXbrPrOXU5+Ma5JFw== X-Gm-Gg: ATEYQzyvCzjeoK0oIQWUqfzk6cmQlNbj7149XeZaQCiIqAuSp6zpUlVS7653SaVRZ43 qme6dPC6+n8CMv3BSOvL5EpWWqTeiBZHFsWB/DWGapUjGEmuenuzt3CxtCYxdHLw/4dH2UAi9Ui x6nkXG6y5B1mPXaiZKGFuwYdJPO22NmlrKRQAFLYDVeKjiEBsW3jqg38IXIU8i/Wh0VrM8HueO5 xD242NGSANKi9CdQe+UHrj3BcScmegtoAlzKsyLGHIA/j+7snQ2SG9VzOwWymXQeS0dIpnJ92TP EiVIhsYJ2K5Zo2aE0eA= X-Received: by 2002:a05:6402:2794:b0:669:c19d:c76 with SMTP id 4fb4d7f45d1cf-66b28469a65mr618262a12.12.1774589542601; Thu, 26 Mar 2026 22:32:22 -0700 (PDT) MIME-Version: 1.0 From: Postgress Cybrosys Date: Fri, 27 Mar 2026 11:02:10 +0530 X-Gm-Features: AQROBzA5myBvudsclaF0DyWoW7xw6M7MD2r4dzNV7as6mUBYkpiP3t4ITuAOQ9c Message-ID: Subject: [PATCH] pg_prewarm: validate that first_block <= last_block To: pgsql-hackers@lists.postgresql.org Content-Type: multipart/mixed; boundary="0000000000004f52e2064dfad303" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000004f52e2064dfad303 Content-Type: multipart/alternative; boundary="0000000000004f52e1064dfad301" --0000000000004f52e1064dfad301 Content-Type: text/plain; charset="UTF-8" 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 postgress@cybrosys.com +91 8606827707 +91 8606827707 --0000000000004f52e1064dfad301 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi psql hackers,

While reviewing contrib/pg_pr= ewarm/pg_prewarm.c, I noticed that
pg_prewarm() does not validate that f= irst_block <=3D last_block after
both values are resolved. When a cal= ler passes a reversed range such
as pg_prewarm('mytable', 'b= uffer', 'main', 100, 50), the function
silently returns 0 wi= thout any indication that the range was empty.
Both block numbers pass t= heir individual bounds checks, so the caller
gets no feedback that anyth= ing went wrong.

The fix adds an explicit check after both endpoints = are fully resolved
(including NULL defaults) and emits an ERROR message.=

Reproduction:

=C2=A0 CREATE TABLE t (id int);
=C2=A0 INSE= RT INTO t SELECT generate_series(1, 10000);

=C2=A0 -- Before patch: = silently returns 0
=C2=A0 SELECT pg_prewarm('t', 'buffer'= ;, 'main', 100, 50);
=C2=A0 =C2=A0pg_prewarm
=C2=A0 ---------= ---
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0
=C2=A0 (1 row)
=C2=A0 -- After patch: raises a clear error

=C2=A0SELECT pg_prewarm= ('t', 'buffer', 'main', 100, 50);
ERROR: =C2=A0e= nding block number cannot be less than starting block number=C2=A0=C2=A0
The patch is attached. It touches only contrib/pg_prewarm/pg_prewarm.c=

-- <= br>

Thanks & Regards,

Jhon k<= /font>

Postgres Specialist

Project & IT Department

=

Cybrosys Technologies<= /span>


Mail=

Mobile

WhatsApp


postgress@c= ybrosys.com

+91 8606827707


--0000000000004f52e1064dfad301-- --0000000000004f52e2064dfad303 Content-Type: text/x-patch; charset="US-ASCII"; name="0001-pg_prewarm-validate-that-first_block-last_block.patch" Content-Disposition: attachment; filename="0001-pg_prewarm-validate-that-first_block-last_block.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_mn8gq4nl0 RnJvbSAyMGY4NTdhOGEyOTZiMTIwMGU0NzdiZmQ5YzE1ZDYyMThhZDM2M2FkIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBkZW1vIDxkZW1vQGdtYWlsLmNvbT4KRGF0ZTogRnJpLCAyNyBN YXIgMjAyNiAxMDo1NjoxNCArMDUzMApTdWJqZWN0OiBbUEFUQ0hdIHBnX3ByZXdhcm06IHZhbGlk YXRlIHRoYXQgZmlyc3RfYmxvY2sgPD0gbGFzdF9ibG9jawoKcGdfcHJld2FybSgpIGFjY2VwdGVk IGEgYmxvY2sgcmFuZ2Ugd2hlcmUgZmlyc3RfYmxvY2sgPiBsYXN0X2Jsb2NrCndpdGhvdXQgY29t cGxhaW50LCBzaWxlbnRseSByZXR1cm5pbmcgMCBibG9ja3MgcHJld2FybWVkLiBCb3RoIGJsb2Nr Cm51bWJlcnMgY291bGQgaW5kaXZpZHVhbGx5IHBhc3MgdGhlaXIgb3duIHJhbmdlIGNoZWNrcywg eWV0IHRoZQpyZXN1bHRpbmcgcmFuZ2UgaXMgbG9naWNhbGx5IGVtcHR5IHdpdGggbm8gaW5kaWNh dGlvbiB0byB0aGUgY2FsbGVyLgoKQWRkIGFuIGV4cGxpY2l0IGNoZWNrIGFmdGVyIGJvdGggZmly c3RfYmxvY2sgYW5kIGxhc3RfYmxvY2sgYXJlIGZ1bGx5CnJlc29sdmVkIChpbmNsdWRpbmcgTlVM TCBkZWZhdWx0cykgc28gdGhhdCB3ZSBjYW4gY29tcGFyZSB0aGUgdHdvCmZpbmFsaXplZCB2YWx1 ZXMgYW5kIGVtaXQgYSBjbGVhciBlcnJvciB3aXRoIGVycmRldGFpbCBzaG93aW5nIHRoZQpleGFj dCB2YWx1ZXMgdGhlIGNhbGxlciBzdXBwbGllZC4KClJlcG9ydGVkLWJ5OiA8cG9zdGdyZXNzQGN5 YnJvc3lzLmNvbT4KQXV0aG9yOiA8cG9zdGdyZXNzQGN5YnJvc3lzLmNvbT4KLS0tCiBjb250cmli L3BnX3ByZXdhcm0vcGdfcHJld2FybS5jIHwgNiArKysrKysKIDEgZmlsZSBjaGFuZ2VkLCA2IGlu c2VydGlvbnMoKykKCmRpZmYgLS1naXQgYS9jb250cmliL3BnX3ByZXdhcm0vcGdfcHJld2FybS5j IGIvY29udHJpYi9wZ19wcmV3YXJtL3BnX3ByZXdhcm0uYwppbmRleCBjMjcxNjA4NjY5My4uYjRk NGE1M2RjODQgMTAwNjQ0Ci0tLSBhL2NvbnRyaWIvcGdfcHJld2FybS9wZ19wcmV3YXJtLmMKKysr IGIvY29udHJpYi9wZ19wcmV3YXJtL3BnX3ByZXdhcm0uYwpAQCAtMTg5LDYgKzE4OSwxMiBAQCBw Z19wcmV3YXJtKFBHX0ZVTkNUSU9OX0FSR1MpCiAJCQkJCSBlcnJtc2coImVuZGluZyBibG9jayBu dW1iZXIgbXVzdCBiZSBiZXR3ZWVuIDAgYW5kICUiIFBSSWQ2NCwKIAkJCQkJCQkobmJsb2NrcyAt IDEpKSkpOwogCX0KKwlpZiAobGFzdF9ibG9jayA8IGZpcnN0X2Jsb2NrKQorCXsKKwkJZXJlcG9y dChFUlJPUiwKKwkJCQkoZXJyY29kZShFUlJDT0RFX0lOVkFMSURfUEFSQU1FVEVSX1ZBTFVFKSwK KwkJCQkgZXJybXNnKCJlbmRpbmcgYmxvY2sgbnVtYmVyIGNhbm5vdCBiZSBsZXNzIHRoYW4gc3Rh cnRpbmcgYmxvY2sgbnVtYmVyIikpKTsKKwl9CiAKIAkvKiBOb3cgd2UncmUgcmVhZHkgdG8gZG8g dGhlIHJlYWwgd29yay4gKi8KIAlpZiAocHR5cGUgPT0gUFJFV0FSTV9QUkVGRVRDSCkKLS0gCjIu MzQuMQoK --0000000000004f52e2064dfad303--