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

From Christophe Pettus
Subject Re: MultiXactMemberControlLock contention on a replica
Date
Msg-id B75597DB-CBE0-4C39-9D6D-56EA1A250A45@thebuild.com
Whole thread Raw
In response to Re: MultiXactMemberControlLock contention on a replica  (Laurenz Albe <laurenz.albe@cybertec.at>)
Responses Re: MultiXactMemberControlLock contention on a replica  (Laurenz Albe <laurenz.albe@cybertec.at>)
List pgsql-general

> On Feb 15, 2021, at 08:15, Laurenz Albe <laurenz.albe@cybertec.at> wrote:
> Right.  I cannot think of any other reason, given that the standby only
> allows reading.  It's just an "xmax", and PostgreSQL needs to read the
> multixact to figure out if it can see the row or not.

OK, I think I see the scenario: A very large number of sessions on the primary all touch or create rows which refer to
aparticular row in another table by foreign key, but they don't modify that row.  A lot of sessions on the secondary
allread the row in the referred-to table, so it has to get all the members of the multixact, and if the multixact
structurehas spilled to disk, that gets very expensive. 

--
-- Christophe Pettus
   xof@thebuild.com




pgsql-general by date:

Previous
From: Thomas Guyot
Date:
Subject: Re: How to post to this mailing list from a web based interface
Next
From: Tom Lane
Date:
Subject: Re: pg_stat_user_tables.n_mod_since_analyze persistence?