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

From Peter Geoghegan
Subject Re: Fix for visibility check on 14.5 fails on tpcc with high concurrency
Date
Msg-id CAH2-Wzm7UtYC5USErGztDzOUAS8kK4HatWPu56TfzEB-SY_rOg@mail.gmail.com
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 Wed, Nov 23, 2022 at 2:54 AM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> 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".

That seems very useful.

Separately, I wonder if it would make sense to add additional
defensive checks to FreezeMultiXactId() for this. There is an
assertion that should catch the presence of multiple updaters in a
single Multi when it looks like we have to generate a new Multi to
carry the XID members forward (typically something we only need to do
during a VACUUM FREEZE). We could at least make that
"Assert(!TransactionIdIsValid(update_xid));" line into a defensive
"can't happen" ereport(). It couldn't hurt, at least -- we already
have a similar relfrozenxid check nearby, added after the "freeze the
dead" bug was fixed.

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Prefetch the next tuple's memory during seqscans
Next
From: Bruce Momjian
Date:
Subject: Re: Prefetch the next tuple's memory during seqscans