Обсуждение: test_compression, test module for low-level compression APIs (for 2b5ba2a0a141)

Hi all,
(Andrew in CC.)

While reading Andrew's commit 2b5ba2a0a141, I was a bit sad to not see
tests for these problems with pglz, applied with the fix down to v14.
Relying on fuzzing is not really cool, because these consume resources
and they may not even hit the correct target, and we want a maximum of
deterministic tests.

And then, I got reminded that one of my pet plugins does something
close to that (used that around 9.5 for some FPW compression
benchmarks):
https://github.com/michaelpq/pg_plugins/tree/main/compress_test

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 would like to apply that down to v14, like the previous commit that
has fixed these cases with pglz.  That should come in handy in case
more bugs pop in this area of the code, especially with more
compression methods in mind.

Any objections and/or comments about that?
--
Michael

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

On Sun, Apr 12, 2026 at 10:20:43PM -0400, Andres Freund wrote:
> 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.

If we care about `make check` rather than `make installcheck`, it
seems to me that a solution already exists in the shape of C function
called through the main regression test suite.  And for the specific
case of this thread, I could live with two new functions in regress.c
that are then called in compression.sql.

Would this idea work for you when it comes to this proposal?
--
Michael

Hi,

On 2026-04-13 12:52:59 +0900, Michael Paquier wrote:
> On Sun, Apr 12, 2026 at 10:20:43PM -0400, Andres Freund wrote:
> > 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.
> 
> If we care about `make check` rather than `make installcheck`

I don't really see the difference WRT that in this case? installcheck still
has regress.so available, no?


> it seems to me that a solution already exists in the shape of C function
> called through the main regression test suite.

I guess that'd work.  I don't really see the point in calling these via SQL,
tbh, but if that's easier for you, using a regress.c helper woul do the trick.


> Would this idea work for you when it comes to this proposal?

Yes.


I think we need to combine about half the modules in src/test/modules, the
current course is absurd:

16:  37
17:  46
18:  49
dev: 62


[Almost] All of them create a new initdb'd cluster. ~50MB of writes for a
short test is insane.  Doing low-level unittests by doing inter-process
communication from psql to the server, marshalling everything through text, is
insane.

Greetings,

Andres Freund

On Mon, Apr 13, 2026 at 7:08 AM Andres Freund <andres@anarazel.de> wrote:
>
> Doing low-level unittests by doing inter-process
> communication from psql to the server, marshalling everything through text, is
> insane.

+1. (I'm more than happy to provide eyes/code/pairing/etc. for C unit
test infrastructure, since I've been pushing on that from the client
side recently.)

--Jacob

On Mon, Apr 13, 2026 at 10:08:16AM -0400, Andres Freund wrote:
> I guess that'd work.  I don't really see the point in calling these via SQL,
> tbh, but if that's easier for you, using a regress.c helper woul do the trick.

Okay, thanks for the opinion.  It makes the addition of more tests
slightly easier as there is no need to rely on an extra wrapper of
what's in pg_lzcompress.h.  I have done that in the attached, with
additions to the main regression test suite.
--
Michael