From: Tom Lane <tgl@sss.pgh.pa.us>
To: Casey & Gina <cg@osss.net>
Cc: Álvaro Herrera <alvherre@kurilemu.de>
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: Issues with blocksize smaller than 8KB
Date: Sun, 19 Oct 2025 16:31:55 -0400
Message-ID: <51147.1760905915@sss.pgh.pa.us> (raw)
In-Reply-To: <38A83DA6-15FF-4FF2-9EB0-C53E63611162@osss.net>
References: <30951.1760899735@sss.pgh.pa.us>
<38A83DA6-15FF-4FF2-9EB0-C53E63611162@osss.net>
Casey & Gina <cg@osss.net> writes:
> On Oct 19, 2025, at 2:48 PM, 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 be used, but happy for the explanation...
I was able to reproduce this error precisely by doing
./configure ... --with-blocksize=1 --with-segsize=10000
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=`expr '(' 1024 / ${blocksize} ')' '*' ${segsize} '*' 1024`
test $? -eq 0 || exit 1
AC_MSG_RESULT([${segsize}GB])
else
RELSEG_SIZE=$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
Attachments:
[text/x-diff] assert-that-RELSEG_SIZE-is-sane.patch (979B, ../51147.1760905915@sss.pgh.pa.us/2-assert-that-RELSEG_SIZE-is-sane.patch)
download | inline diff:diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.cindex 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[] = {
{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 <= 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
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: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, cg@osss.net, alvherre@kurilemu.de, pgsql-bugs@lists.postgresql.org
Subject: Re: Issues with blocksize smaller than 8KB
In-Reply-To: <51147.1760905915@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox