Hello Dimos
On 2022-Nov-22, Dimos Stamatakis wrote:
> When running tpcc on sysbench with high concurrency (96 threads, scale
> factor 5) we realized that a fix for visibility check (introduced in
> PG-14.5) causes sysbench to fail in 1 out of 70 runs.
> The error is the following:
>
> SQL error, errno = 0, state = 'XX000': new multixact has more than one updating member
Ouch.
I did not remember any reports of this. Searching I found this recent
one:
https://postgr.es/m/17518-04e368df5ad7f2ee@postgresql.org
However, the reporter there says they're using 12.10, and according to
src/tools/git_changelog the commit appeared only in 12.12:
Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
Branch: master Release: REL_15_BR [adf6d5dfb] 2022-06-27 08:21:08 +0300
Branch: REL_14_STABLE Release: REL_14_5 [e24615a00] 2022-06-27 08:24:30 +0300
Branch: REL_13_STABLE Release: REL_13_8 [7ba325fd7] 2022-06-27 08:24:35 +0300
Branch: REL_12_STABLE Release: REL_12_12 [af530898e] 2022-06-27 08:24:36 +0300
Branch: REL_11_STABLE Release: REL_11_17 [b49889f3c] 2022-06-27 08:24:37 +0300
Branch: REL_10_STABLE Release: REL_10_22 [4822b4627] 2022-06-27 08:24:38 +0300
Fix visibility check when XID is committed in CLOG but not in procarray.
[...]
Thinking further, one problem in tracking this down is that at this
point the multixact in question is *being created*, so we don't have a
WAL trail we could trace through.
I suggest that we could improve that elog() so that it includes the
members of the multixact in question, which could help us better
understand what is going on.
> This commit was supposed to fix a race condition during the visibility
> check. Please let us know whether you are aware of this issue and if
> there is a quick fix.
I don't think so.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/