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

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: Fix for visibility check on 14.5 fails on tpcc with high concurrency
Дата
Msg-id 20221124094948.w4kdf3siq42vosry@alvherre.pgsql
обсуждение исходный текст
Ответ на Re: Fix for visibility check on 14.5 fails on tpcc with high concurrency  (Peter Geoghegan <pg@bowt.ie>)
Ответы Re: Fix for visibility check on 14.5 fails on tpcc with high concurrency  (Dimos Stamatakis <dimos.stamatakis@servicenow.com>)
Список pgsql-hackers
On 2022-Nov-23, Peter Geoghegan wrote:

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

Okay, pushed to all branches.

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

Hmm, agreed.  I'll see about that separately.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/
"I'm always right, but sometimes I'm more right than other times."
                                                  (Linus Torvalds)



В списке pgsql-hackers по дате отправления:

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: Prefetch the next tuple's memory during seqscans
Следующее
От: Maxim Orlov
Дата:
Сообщение: Re: [BUG] FailedAssertion in SnapBuildPurgeOlderTxn