From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, myon(at)debian(dot)org, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: 15beta1 test failure on mips in isolation/expected/stats |
Date: | 2022-05-20 15:34:55 |
Message-ID: | 349056.1653060895@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
>> I think what might be happening is that the transactional stats updates get
>> reported by s2 *before* the non-transactional stats updates come in from
>> s1. I.e. the pgstat_report_stat() at the end of s2_commit_prepared_a does a
>> report, because the machine is slow enough for it to be "time to reports stats
>> again". Then s1 reports its non-transactional stats.
> Sounds plausible. And I left the test loop running, and it's now past
> 100 consecutive successes, so I think this change definitely "fixes" it.
In the light of morning, at least half of the parameter dependency is
now obvious: the problematic test case involves a prepared transaction,
so it fails completely with max_prepared_transactions = 0. The isolation
test harness masks that by matching against stats_1.out, but it's not
really a "success".
My numbers do still suggest that there's a weak dependence on
max_connections, but it's possible that that's a mirage. I did not run
enough test cycles to be able to say positively that that's a real effect
(and the machine's slow enough that I'm not excited about doing so).
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Oleksii Kliukin | 2022-05-20 17:36:38 | Re: Limiting memory allocation |
Previous Message | osumi.takamichi@fujitsu.com | 2022-05-20 14:53:22 | RE: Build-farm - intermittent error in 031_column_list.pl |