Re: POC: make mxidoff 64 bits - Mailing list pgsql-hackers
| From | Alexander Lakhin |
|---|---|
| Subject | Re: POC: make mxidoff 64 bits |
| Date | |
| Msg-id | b7faf07c-7d2c-4f35-8c43-392e057153ef@gmail.com Whole thread Raw |
| In response to | Re: POC: make mxidoff 64 bits (Heikki Linnakangas <hlinnaka@iki.fi>) |
| Responses |
Re: POC: make mxidoff 64 bits
|
| List | pgsql-hackers |
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
pgsql-hackers by date: