Re: Fix for visibility check on 14.5 fails on tpcc with high concurrency - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Fix for visibility check on 14.5 fails on tpcc with high concurrency
Date
Msg-id 20221123105351.ykjtpokwsuw2ol73@alvherre.pgsql
Whole thread Raw
In response to Re: Fix for visibility check on 14.5 fails on tpcc with high concurrency  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: Fix for visibility check on 14.5 fails on tpcc with high concurrency
List pgsql-hackers
On 2022-Nov-23, Alvaro Herrera wrote:

> 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.

Something like the attached.  It would result in output like this:
WARNING:  new multixact has more than one updating member: 0 2[17378 (keysh), 17381 (nokeyupd)]

Then it should be possible to trace (in pg_waldump output) the
operations of each of the transactions that have any status in the
multixact that includes some form of "upd".

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/
"Just treat us the way you want to be treated + some extra allowance
 for ignorance."                                    (Michael Brusser)

Attachment

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Perform streaming logical transactions by background workers and parallel apply
Next
From: David Rowley
Date:
Subject: Re: [PATCH] Enable using llvm jitlink as an alternative llvm jit linker of old Rtdyld.