From: Tom Lane <tgl@sss.pgh.pa.us>
To: Casey Shobe <casey.allen.shobe@icloud.com>
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: Issues with blocksize smaller than 8KB
In-reply-to: <C5DC82D6-C76D-4E8F-BC2E-DF03EFC4FA24@icloud.com>
References: <C5DC82D6-C76D-4E8F-BC2E-DF03EFC4FA24@icloud.com>
Comments: In-reply-to Casey Shobe <casey.allen.shobe@icloud.com>
	message dated "Fri, 17 Oct 2025 11:42:12 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2038567.1760805945.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Sat, 18 Oct 2025 12:45:45 -0400
Message-ID: <2038568.1760805945@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2038568.1760805945%40sss.pgh.pa.us>
Precedence: bulk

Casey Shobe <casey.allen.shobe@icloud.com> writes:
> I have been comparing performance of postgresql (18.0) compiled for vari=
ous block sizes etc., and found that while 8kb and 16kb builds work fine, =
a 4kb build does not, with identical configuration.  When I try to initial=
ize pgbench, --scale=3D10 works fine, but the --scale=3D100 I was trying a=
nd even just --scale=3D20 result in a long delay on the vacuum analyze ste=
p followed by Postgres crashing due to a segmentation fault.
> I also found that initdb fails when I compile for a blocksize of either =
1KB or 2KB build:

> 2025-10-17 15:39:13.182 UTC [97433] DETAIL:  The database cluster was in=
itialized with RELSEG_SIZE 1895825408, but the server was compiled with RE=
LSEG_SIZE 1895825408.
> 2025-10-17 15:39:13.182 UTC [97433] HINT:  It looks like you need to rec=
ompile or initdb.

I could not reproduce any of these misbehaviors here.  I suspect you
have a build process problem, ie failure to clean out all compilation
products when reconfiguring.  You need at least "make clean", and
personally I usually use "make distclean" or "git clean -dfxq".

(In theory, using --enable-depend would let you be sloppy about this,
but I've never particularly trusted that option.  It definitely will
not work to change configure settings without that.)

			regards, tom lane