On Mon, 2021-02-15 at 12:40 -0800, Christophe Pettus wrote:
> > On Feb 15, 2021, at 08:15, Laurenz Albe 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 ca
> On Feb 15, 2021, at 08:15, Laurenz Albe 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 lar
On Mon, 2021-02-15 at 08:03 -0800, Christophe Pettus wrote:
> On Feb 15, 2021, at 07:47, Laurenz Albe wrote:
> > 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 st
> On Feb 15, 2021, at 07:47, Laurenz Albe wrote:
> 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.
Why does the secondary need to read the
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 co
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 yo
