Message-ID: <68ebab07.df0a0220.3222eb.2022@mx.google.com>
Sender: Michael Banck <mbanck@gmail.com>
Date: Sun, 12 Oct 2025 15:20:07 +0200
From: Michael Banck <mbanck@gmx.net>
To: Alexander Lakhin <exclusion@gmail.com>
Cc: Thomas Munro <thomas.munro@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>,
	Michael Paquier <michael@paquier.xyz>,
	pgsql-hackers@lists.postgresql.org
Subject: Re: GNU/Hurd portability patches
References: <68d3cbe8.5d0a0220.65f10.da5f@mx.google.com>
 <3314741.1758724126@sss.pgh.pa.us>
 <68d413a3.a70a0220.24c74c.8be9@mx.google.com>
 <68d55c1e.050a0220.6136.4224@mx.google.com>
 <3771131.1758819153@sss.pgh.pa.us>
 <68d629f2.050a0220.3685b9.5ce2@mx.google.com>
 <CA+hUKGJE_moUF74c97GkoP6RaknRMoeFOednXe2FyXnS_bOTFQ@mail.gmail.com>
 <e2bf13d1-f152-4d1d-acbe-a8c4c41611fd@gmail.com>
 <68eb6761.7b0a0220.1711d0.1819@mx.google.com>
 <b87a0112-6235-4d87-886b-d1c79c0e0543@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <b87a0112-6235-4d87-886b-d1c79c0e0543@gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: 
 <https://www.postgresql.org/message-id/68ebab07.df0a0220.3222eb.2022%40mx.google.com>
Precedence: bulk

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