Re: Issues with blocksize smaller than 8KB

Casey & Gina <cg(at)osss(dot)net> writes:
> On Oct 19, 2025, at 2:48 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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