Feedback-ID: id4a34324:Fastmail
Date: Sun, 12 Apr 2026 22:20:43 -0400
From: Andres Freund <andres@anarazel.de>
To: Michael Paquier <michael@paquier.xyz>
Cc: Postgres hackers <pgsql-hackers@lists.postgresql.org>,
	Andrew Dunstan <andrew@dunslane.net>
Subject: Re: test_compression, test module for low-level compression APIs
 (for 2b5ba2a0a141)
Message-ID: <pzafmppohkmqixgswjcyi6lyf2nsmbcyty4l6lciamskjl5nem@3i2am4uetkd2>
References: <adw647wuGjh1oU6p@paquier.xyz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <adw647wuGjh1oU6p@paquier.xyz>
Archived-At: 
 <https://www.postgresql.org/message-id/pzafmppohkmqixgswjcyi6lyf2nsmbcyty4l6lciamskjl5nem%403i2am4uetkd2>
Precedence: bulk

Hi,

On 2026-04-13 09:37:55 +0900, Michael Paquier wrote:
> With this infrastructure already at hand, implementing the
> problematic tests with corrupted varlenas was a matter of minutes,
> leading me to the attached patch (bonus points for check_comprete and
> rawsize)

I think it doesn't scale to have a whole postgres cluster for a test that
takes a few milliseconds.  The amount of IO one run of all of postgres' tests
is doing is getting unmangeable, and lots of clusters that are used for a a
second or two that are immediately destroyed contributes substantially to
that.

One PG_TEST_NOCLEAN=1 run with meson ends up with a 33GB testrun/ directory.
And that's without even counting all the pg_regress tests, because there's no
convenient way to disable that.  On a smaller machine much of that will be
written to disk due to cache/memory pressure.

There's really no reason for something like this to be a test doing tests via
SQL from what I can tell.

If it does not to be via SSL, can we please start to find a way to combine
tiny stuff like this?  We're working hard at making our tests grow
unsustainable.

Greetings,

Andres Freund