From: Tom Lane <tgl@sss.pgh.pa.us>
To: Casey & Gina <cg@osss.net>
cc: =?utf-8?Q?=C3=81lvaro_Herrera?= <alvherre@kurilemu.de>,
        pgsql-bugs@lists.postgresql.org
Subject: Re: Issues with blocksize smaller than 8KB
In-reply-to: <38A83DA6-15FF-4FF2-9EB0-C53E63611162@osss.net>
References: <30951.1760899735@sss.pgh.pa.us>
 <38A83DA6-15FF-4FF2-9EB0-C53E63611162@osss.net>
Comments: In-reply-to Casey & Gina <cg@osss.net>
	message dated "Sun, 19 Oct 2025 15:42:23 -0400"
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0"
Content-ID: <51007.1760905838.0@sss.pgh.pa.us>
Date: Sun, 19 Oct 2025 16:31:55 -0400
Message-ID: <51147.1760905915@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/51147.1760905915%40sss.pgh.pa.us>
Precedence: bulk

------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <51007.1760905838.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable

Casey & Gina <cg@osss.net> writes:
> On Oct 19, 2025, at 2:48=E2=80=AFPM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Incautious use of --with-segsize could perhaps result in RELSEG_SIZE
>> being too big for an int ...

> This must have been it, though the same --with-segsize value worked for =
larger blocksizes.
> Perhaps configure could throw an error if too large of a value were to b=
e used, but happy for the explanation...

I was able to reproduce this error precisely by doing

./configure ... --with-blocksize=3D1 --with-segsize=3D10000

so I guess that's what you did (and you must have ignored the boatload
of compiler warnings that ensued).  configure does try to notice
an overflow, but it seems to expect that expr(1) will complain about
a larger-than-int result:

AC_MSG_CHECKING([for segment size])
if test $segsize_blocks -eq 0; then
  # this expression is set up to avoid unnecessary integer overflow
  # blocksize is already guaranteed to be a factor of 1024
  RELSEG_SIZE=3D`expr '(' 1024 / ${blocksize} ')' '*' ${segsize} '*' 1024`
  test $? -eq 0 || exit 1
  AC_MSG_RESULT([${segsize}GB])
else
  RELSEG_SIZE=3D$segsize_blocks
  AC_MSG_RESULT([${RELSEG_SIZE} blocks])
fi

At least on my Linux box, there's no complaint, you just get back
the correct value of 10485760000.  So that's not great, and it's
even less great that --with-segsize-blocks isn't checked at all.

The natural way to deal with this would be to add a test like

if test $RELSEG_SIZE -le 0 -o $RELSEG_SIZE -gt 2147483647; then
   ... fail ...

but this assumes a fact not in evidence, that test(1) will do
wider-than-int arithmetic sanely.  (Just because expr(1) does
doesn't prove a lot about test(1), IMO.)  I'm even less sure
that I want to rely on meson to do it right.  So I think we'd
better leave it to the C compiler, as attached.

			regards, tom lane


------- =_aaaaaaaaaa0
Content-Type: text/x-diff; name="assert-that-RELSEG_SIZE-is-sane.patch";
	charset="us-ascii"
Content-ID: <51007.1760905838.2@sss.pgh.pa.us>
Content-Description: assert-that-RELSEG_SIZE-is-sane.patch
Content-Transfer-Encoding: quoted-printable

diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transa=
m/xlog.c
index eceab341255..2e1da5c714b 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -39,6 +39,7 @@
 #include "postgres.h"
 =

 #include <ctype.h>
+#include <limits.h>
 #include <math.h>
 #include <time.h>
 #include <fcntl.h>
@@ -202,6 +203,15 @@ const struct config_enum_entry archive_mode_options[]=
 =3D {
 	{NULL, 0, false}
 };
 =

+/*
+ * RELSEG_SIZE must fit into BlockNumber; but since we expose its value
+ * as an integer GUC, it actually needs to fit in signed int.  It's worth
+ * having a cross-check for this since configure's --with-segsize options
+ * could let people select insane values.
+ */
+StaticAssertDecl(RELSEG_SIZE > 0 && RELSEG_SIZE <=3D INT_MAX,
+				 "RELSEG_SIZE must fit in an integer");
+
 /*
  * Statistics for current checkpoint are collected in this global struct.
  * Because only the checkpointer or a stand-alone backend can perform

------- =_aaaaaaaaaa0--