Re: 15beta1 test failure on mips in isolation/expected/stats
От
Tom Lane
Тема
Re: 15beta1 test failure on mips in isolation/expected/stats
Дата
Msg-id
349056.1653060895@sss.pgh.pa.us
Ответ на
Список
Дерево обсуждения
15beta1 test failure on mips in isolation/expected/stats Christoph Berg <myon@debian.org>
Re: 15beta1 test failure on mips in isolation/expected/stats Tom Lane <tgl@sss.pgh.pa.us>
Re: 15beta1 test failure on mips in isolation/expected/stats Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Re: 15beta1 test failure on mips in isolation/expected/stats Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Re: 15beta1 test failure on mips in isolation/expected/stats Tom Lane <tgl@sss.pgh.pa.us>
Re: 15beta1 test failure on mips in isolation/expected/stats Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Re: 15beta1 test failure on mips in isolation/expected/stats Andres Freund <andres@anarazel.de>
Re: 15beta1 test failure on mips in isolation/expected/stats Tom Lane <tgl@sss.pgh.pa.us>
Re: 15beta1 test failure on mips in isolation/expected/stats Andres Freund <andres@anarazel.de>
Re: 15beta1 test failure on mips in isolation/expected/stats Tom Lane <tgl@sss.pgh.pa.us>
Re: 15beta1 test failure on mips in isolation/expected/stats Andres Freund <andres@anarazel.de>
Re: 15beta1 test failure on mips in isolation/expected/stats Christoph Berg <myon@debian.org>
Re: 15beta1 test failure on mips in isolation/expected/stats Tom Lane <tgl@sss.pgh.pa.us>
Re: 15beta1 test failure on mips in isolation/expected/stats Andres Freund <andres@anarazel.de>
Re: 15beta1 test failure on mips in isolation/expected/stats Tom Lane <tgl@sss.pgh.pa.us>
I wrote: > Andres Freund 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
В списке pgsql-hackers по дате отправления
От: osumi.takamichi@fujitsu.com
Дата: