Message-ID: <b7faf07c-7d2c-4f35-8c43-392e057153ef@gmail.com>
Date: Mon, 15 Dec 2025 10:00:00 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: POC: make mxidoff 64 bits
To: Heikki Linnakangas <hlinnaka@iki.fi>,
 Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>,
 Maxim Orlov <orlovmg@gmail.com>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>,
 Alexander Korotkov <aekorotkov@gmail.com>, wenhui qiu
 <qiuwenhuifx@gmail.com>,
 Postgres hackers <pgsql-hackers@lists.postgresql.org>
References: 
 <CACG=ezaWg7_nt-8ey4aKv2w9LcuLthHknwCawmBgEeTnJrJTcw@mail.gmail.com>
 <CAGjGUA+BfcWyccNN4=tHsW_E-koRxbg8h8ut6hjvPsHMgmek6w@mail.gmail.com>
 <CACG=ezYbYO_KHWdeDedbDcY0tOS0JfaqBxG3=bG5+DdsDK4MpQ@mail.gmail.com>
 <CACG=ezYpZRPwoRCz_h3Qerd3XJNdpTHCpwGbZphNdy26tA4_qQ@mail.gmail.com>
 <36531c0e-292c-409d-bbc7-a252cf6e910a@iki.fi>
 <54aa8f65-f0e4-4464-b543-e0399c1cab1e@iki.fi>
 <CACG=ezYUJSvnuxntkURNWo_1vZ+AtmcQfqd_h6WgDzGaudfw+Q@mail.gmail.com>
 <4a9dda70-0af7-41a4-9636-b168f2fc48ef@iki.fi>
 <46cc45e9-fddd-44bc-bcb3-96889aafd921@iki.fi>
 <CAExHW5tUEkiQrvm9hgccjKUNkWBnJ5_HDUrAwiHBTxu+Vuj29Q@mail.gmail.com>
 <6c298bc4-7029-4c1d-bf16-3e094842ce32@iki.fi>
 <CAExHW5t3kzJiVqmoqCLyGmfkTjD4Rwa27kXH-S_XvHWLkM2fzw@mail.gmail.com>
 <CAExHW5ucnoyjd6p7UVVhQTeV7hc8-vX81ti8f7sU0COqfUWzQg@mail.gmail.com>
 <2c62322e-a0e3-49cd-b369-370718a8efd8@iki.fi>
 <CAExHW5s_uNeD_xYjdbSR8khMXwWJQOY9Qg=j4T+5KOfGz5-RsQ@mail.gmail.com>
 <3624730d-6dae-42bf-9458-76c4c965fb27@iki.fi>
Content-Language: en-US
From: Alexander Lakhin <exclusion@gmail.com>
In-Reply-To: <3624730d-6dae-42bf-9458-76c4c965fb27@iki.fi>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/b7faf07c-7d2c-4f35-8c43-392e057153ef%40gmail.com>
Precedence: bulk

Hello Heikki,

09.12.2025 14:00, Heikki Linnakangas wrote:
> Committed with that and some other minor cleanups. Thanks everyone! This patch has been brewing for a while :-).

I've spotted a couple of failures of new test 007_multixact_conversion at
buildfarm:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=urutu&dt=2025-12-09%2020%3A40%3A53
007_multixact_conversion_basic_oldnode.log:
...
2025-12-09 22:33:39.299 CET [2872679][client backend][21/2:0] LOG: statement: SET log_statement=none
     ;
2025-12-09 22:36:39.025 CET [2871745][postmaster][:0] LOG:  received immediate shutdown request
(180 seconds timeout)

https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=canebrake&dt=2025-12-14%2023%3A53%3A48
007_multixact_conversion_basic_oldnode.log:
...
2025-12-15 01:57:01.380 CET [2178307][client backend][21/2:0] LOG: statement: SET log_statement=none
     ;
2025-12-15 02:00:01.020 CET [2177271][postmaster][:0] LOG:  received immediate shutdown request
(180 seconds timeout)

Both occurred on JIT-enabled animals (moreover, JIT is provided by a debug
build of LLVM), so these animals are very slow.

Looking at other urutu's runs, we can see:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=urutu&dt=2025-12-10%2013%3A06%3A35
007_multixact_conversion_basic_oldnode.log::
2025-12-10 14:37:05.254 CET [2322763][client backend][21/2:0] LOG: statement: SET log_statement=none
     ;
2025-12-10 14:39:21.784 CET [2322610][client backend][:0] LOG: disconnection: session time: 0:02:16.878 user=bf 
database=postgres host=[local]
(136 seconds)

https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=urutu&dt=2025-12-10%2017%3A43%3A02
2025-12-10 19:20:30.310 CET [1785680][client backend][21/2:0] LOG: statement: SET log_statement=none
     ;
2025-12-10 19:22:41.734 CET [1784967][client backend][:0] LOG: disconnection: session time: 0:02:11.903 user=bf 
database=postgres host=[local]
(133 seconds)

Though major runs show timing under 80 seconds, e.g.:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=urutu&dt=2025-12-14%2021%3A20%3A49
2025-12-14 22:48:53.764 CET [3751001][client backend][21/2:0] LOG: statement: SET log_statement=none
     ;
2025-12-14 22:49:57.223 CET [3750961][client backend][:0] LOG: disconnection: session time: 0:01:03.571 user=bf 
database=postgres host=[local]
(64 seconds)

And a couple of other (successful) canebrake's runs:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=canebrake&dt=2025-12-14%2021%3A09%3A31
2025-12-14 22:59:48.951 CET [3761649][client backend][21/2:0] LOG: statement: SET log_statement=none
     ;
2025-12-14 23:01:26.274 CET [3761608][client backend][:0] LOG: disconnection: session time: 0:01:37.441 user=bf 
database=postgres host=[local]
(98 seconds)

https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=canebrake&dt=2025-12-14%2012%3A03%3A29
2025-12-14 13:59:29.205 CET [1564673][client backend][21/2:0] LOG: statement: SET log_statement=none
     ;
2025-12-14 14:01:15.208 CET [1564633][client backend][:0] LOG: disconnection: session time: 0:01:46.147 user=bf 
database=postgres host=[local]
(106 seconds)

Thus, it looks like these animals can hit 180 seconds timeout with some
external factors (concurrent load?) that make them run 2-3 times slower...

Best regards,
Alexander