Message-ID: <cbbbb5ae-0219-4c67-a52b-fa03119f6701@iki.fi>
Date: Mon, 15 Dec 2025 16:31:13 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: POC: make mxidoff 64 bits
To: Alexander Lakhin <exclusion@gmail.com>,
 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>
 <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>
 <b7faf07c-7d2c-4f35-8c43-392e057153ef@gmail.com>
Content-Language: en-US
From: Heikki Linnakangas <hlinnaka@iki.fi>
In-Reply-To: <b7faf07c-7d2c-4f35-8c43-392e057153ef@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/cbbbb5ae-0219-4c67-a52b-fa03119f6701%40iki.fi>
Precedence: bulk

On 15/12/2025 10:00, Alexander Lakhin wrote:
> 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:
> ...
> 
> 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...

Hmm, so it's hitting the timeout while running the multixid generation 
workload part of the test. The workload keeps 20 parallel connections 
open, using them in a round-robin fashion, and apparently the timeout 
spans the whole duration of each connection rather than the individual 
queries run on them.

On my laptop with jit_above_cost=0 and jit_optimize_above_cost=1000, 
like on those buildfarm animals, the multixid generation workload runs 
in under 10 s. I suppose it could be 20x slower on a slow, busy system. 
So the straightforward fix is to bump up the timeout.

I'm tempted to force "jit=off" here, as the multixid generation is not 
really the thing that's being tested here. It's just used to generate 
multixids in the cluster before the upgrade. Then again, the point of 
forcing JIT in these buildfarm members is to test JITting as part of 
everything else that wasn't originally written as a JIT test.

- Heikki