Re: MultiXactMemberControlLock contention on a replica - Mailing list pgsql-general

From Laurenz Albe
Subject Re: MultiXactMemberControlLock contention on a replica
Date
Msg-id 99c0f12af81e0370c2caddb75cd8150a1a818dd8.camel@cybertec.at
Whole thread Raw
In response to MultiXactMemberControlLock contention on a replica  (Christophe Pettus <xof@thebuild.com>)
Responses Re: MultiXactMemberControlLock contention on a replica  (Christophe Pettus <xof@thebuild.com>)
List 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 by date:

Previous
From: Laurenz Albe
Date:
Subject: Re: certs in connection string
Next
From: Christophe Pettus
Date:
Subject: Re: MultiXactMemberControlLock contention on a replica