Re: MultiXactMemberControlLock contention on a replica

Поиск
Список
Период
Сортировка
От Laurenz Albe
Тема Re: MultiXactMemberControlLock contention on a replica
Дата
Msg-id 99c0f12af81e0370c2caddb75cd8150a1a818dd8.camel@cybertec.at
обсуждение исходный текст
Ответ на MultiXactMemberControlLock contention on a replica  (Christophe Pettus <xof@thebuild.com>)
Ответы Re: MultiXactMemberControlLock contention on a replica  (Christophe Pettus <xof@thebuild.com>)
Список pgsql-general
On Fri, 2021-02-12 at 11:11 -0800, Christophe Pettus wrote:
> On a whole fleet of load-balanced replicas, we saw an incident where one particular query
>  started backing up on MultiXactMemberControlLock and multixact_member.  There was no sign
>  of this backup on the primary.  Under what conditions would there be enough multixact
>  members on a replica (where you can't do UPDATE / SELECT FOR UPDATE / FOR SHARE) to start
>  spilling to disk?

Multixacts are replicated, and they are only generated on the primary.

So my guess would be that the difference between primary and standby is not that a
different number of multixacts are created, but that you need to read them on
the standby and not on the primary.

Are the multixacts caused by foreign keys or by subtransactions?

Yours,
Laurenz Albe
-- 
Cybertec | https://www.cybertec-postgresql.com




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

Предыдущее
От: Laurenz Albe
Дата:
Сообщение: Re: certs in connection string
Следующее
От: Christophe Pettus
Дата:
Сообщение: Re: MultiXactMemberControlLock contention on a replica