Re: GNU/Hurd portability patches

On Sun, Oct 12, 2025 at 04:00:00PM +0300, Alexander Lakhin wrote:
> Hi Michael,
>
> 12.10.2025 11:31, Michael Banck wrote:
> >
> > Any way to easily reproduce this? It happened only once on fruitcrow so
> > far.
>
> I'd say it happens pretty often when `make check` doesn't hang (so it
> takes an hour or two for me to reproduce).
>
> Though now that you've mentioned MAX_CONNECTIONS => '3', I also tried:
> EXTRA_REGRESS_OPTS="--max-connections=3" make -s check
> and it passed 6 iterations for me. Iteration 7 failed with:
> not ok 213   + partition_aggregate                      1027 ms
>
> --- /home/demo/postgresql/src/test/regress/expected/partition_aggregate.out 2025-10-11 10:04:36.000000000 +0100
> +++ /home/demo/postgresql/src/test/regress/results/partition_aggregate.out 2025-10-12 13:02:05.000000000 +0100
> @@ -1476,14 +1476,14 @@
>  (15 rows)
>
>  SELECT x, sum(y), avg(y), sum(x+y), count(*) FROM pagg_tab_para GROUP BY x HAVING avg(y) < 7 ORDER BY 1, 2, 3;
> - x  | sum  |        avg         |  sum  | count
> -----+------+--------------------+-------+-------
> -  0 | 5000 | 5.0000000000000000 |  5000 |  1000
> -  1 | 6000 | 6.0000000000000000 |  7000 |  1000
> - 10 | 5000 | 5.0000000000000000 | 15000 |  1000
> - 11 | 6000 | 6.0000000000000000 | 17000 |  1000
> - 20 | 5000 | 5.0000000000000000 | 25000 |  1000
> - 21 | 6000 | 6.0000000000000000 | 27000 |  1000
> + x  | sum  |            avg             |  sum  | count
> +----+------+----------------------------+-------+-------
> +  0 | 5000 |         5.0000000000000000 |  5000 |  1000
> +  1 | 6000 |         6.0000000000000000 |  7000 |  1000
> + 10 | 5000 | 0.000000052757140846001326 | 15000 |  1000
> + 11 | 6000 |         6.0000000000000000 | 17000 |  1000
> + 20 | 5000 |         5.0000000000000000 | 25000 |  1000
> + 21 | 6000 |         6.0000000000000000 | 27000 |  1000
>  (6 rows)

euh.

> Then another 6 iterations passed, seventh one hanged. Then 10 iterations
> passed.
>
> With  EXTRA_REGRESS_OPTS="--max-connections=10" make -s check, I got:
> 2025-10-12 13:52:58.559 BST client backend[15475] pg_regress/constraints
> STATEMENT:  ALTER TABLE notnull_tbl2 ALTER a DROP NOT NULL;
> !!!wrapper_handler[15479]| postgres_signal_arg: 30, PG_NSIG: 33
> !!!wrapper_handler[15476]| postgres_signal_arg: 30, PG_NSIG: 33
> !!!wrapper_handler[15476]| postgres_signal_arg: 28481392, PG_NSIG: 33
> TRAP: failed Assert("postgres_signal_arg < PG_NSIG"), File: "pqsignal.c", Line: 94, PID: 15476
> postgres(ExceptionalCondition+0x5a) [0x1006af78a]
> postgres(+0x70f59a) [0x10070f59a]
> /lib/x86_64-gnu/libc.so.0.3(+0x39fee) [0x102b89fee]
> /lib/x86_64-gnu/libc.so.0.3(+0x39fdd) [0x102b89fdd]
>
> on iteration 5.
>
> So we can conclude that the issue with signals is better reproduced with
> higher concurrency.
>
> 28481392 (0x1b29770) is pretty close to 28476608 (0x1b284c0), which I
> showed before, so numbers are apparently not random.

Ok, so it seems to do that for different tests/statements.

I'll try to reproduce it here with the above --max-connections=10,
thanks.

Michael