From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, mailings(at)oopsware(dot)de, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_verify_checksums failure with hash indexes |
Date: | 2018-09-05 18:28:13 |
Message-ID: | 20180905182813.GE2726@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Sep 05, 2018 at 12:16:00AM -0400, Tom Lane wrote:
> Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> writes:
>> Does anybody else have any idea on how can we write a test for
>> non-default block size or if we already have anything similar?
>
> Build with a non-default BLCKSZ and see if the regression tests pass.
> There's no way that a build with BLCKSZ x can run any tests for
> BLCKSZ y.
Or we could implement block-level configuration at initdb time? That's
what Andres has done for WAL segment size recently.
/me hides and runs fast
> Note that you can expect some plan variations from a different BLCKSZ,
> so there'd be at least a few "failures" in the regression tests, which'd
> require manual inspection. Otherwise this could be delegated to a
> buildfarm animal using a nonstandard BLCKSZ.
Last time I did that I saw only plan diffs, which was a couple of weeks
ago.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2018-09-05 18:35:52 | Re: JIT compiling with LLVM v12 |
Previous Message | Alvaro Herrera | 2018-09-05 18:20:03 | Re: pgsql: Clean up after TAP tests in oid2name and vacuumlo. |