| From: | Christophe Pettus <xof(at)thebuild(dot)com> |
|---|---|
| To: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
| Cc: | "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: MultiXactMemberControlLock contention on a replica |
| Date: | 2021-02-15 20:40:54 |
| Message-ID: | B75597DB-CBE0-4C39-9D6D-56EA1A250A45@thebuild.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
> On Feb 15, 2021, at 08:15, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)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 a particular row in another table by foreign key, but they don't modify that row. A lot of sessions on the secondary all read the row in the referred-to table, so it has to get all the members of the multixact, and if the multixact structure has spilled to disk, that gets very expensive.
--
-- Christophe Pettus
xof(at)thebuild(dot)com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2021-02-15 20:55:10 | Re: pg_stat_user_tables.n_mod_since_analyze persistence? |
| Previous Message | Thomas Guyot | 2021-02-15 20:34:03 | Re: How to post to this mailing list from a web based interface |