| From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
|---|---|
| To: | Christophe Pettus <xof(at)thebuild(dot)com>, "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 15:47:39 |
| Message-ID: | 99c0f12af81e0370c2caddb75cd8150a1a818dd8.camel@cybertec.at |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Christophe Pettus | 2021-02-15 16:03:17 | Re: MultiXactMemberControlLock contention on a replica |
| Previous Message | Laurenz Albe | 2021-02-15 15:31:56 | Re: [LDAPS] Test connection user with ldaps server |