From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Casey Shobe <casey(dot)allen(dot)shobe(at)icloud(dot)com> |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: Issues with blocksize smaller than 8KB |
Date: | 2025-10-18 16:45:45 |
Message-ID: | 2038568.1760805945@sss.pgh.pa.us |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Casey Shobe <casey(dot)allen(dot)shobe(at)icloud(dot)com> writes:
> I have been comparing performance of postgresql (18.0) compiled for various 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 initialize pgbench, --scale=10 works fine, but the --scale=100 I was trying and even just --scale=20 result in a long delay on the vacuum analyze step 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 initialized with RELSEG_SIZE 1895825408, but the server was compiled with RELSEG_SIZE 1895825408.
> 2025-10-17 15:39:13.182 UTC [97433] HINT: It looks like you need to recompile 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
From | Date | Subject | |
---|---|---|---|
Next Message | Casey & Gina | 2025-10-19 14:44:01 | Re: Issues with blocksize smaller than 8KB |
Previous Message | Álvaro Herrera | 2025-10-18 16:22:16 | Re: BUG #19074: pg_dump from v18 loses the NOT NULL flag in the inherited table field when dumping v17-databases |