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