Re: Fix for visibility check on 14.5 fails on tpcc with high concurrency

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Dimos Stamatakis <dimos(dot)stamatakis(at)servicenow(dot)com>
Cc: "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Fix for visibility check on 14.5 fails on tpcc with high concurrency
Date: 2022-11-23 10:53:51
Message-ID: 20221123105351.ykjtpokwsuw2ol73@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 Content-Type Size
servicenow.patch text/x-diff 628 bytes

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2022-11-23 11:08:20 Re: [PATCH] Enable using llvm jitlink as an alternative llvm jit linker of old Rtdyld.
Previous Message Amit Kapila 2022-11-23 10:25:42 Re: Perform streaming logical transactions by background workers and parallel apply