Re: MultiXactMemberControlLock contention on a replica

Поиск
Список
Период
Сортировка
От Christophe Pettus
Тема Re: MultiXactMemberControlLock contention on a replica
Дата
Msg-id B75597DB-CBE0-4C39-9D6D-56EA1A250A45@thebuild.com
обсуждение исходный текст
Ответ на Re: MultiXactMemberControlLock contention on a replica  (Laurenz Albe <laurenz.albe@cybertec.at>)
Ответы Re: MultiXactMemberControlLock contention on a replica  (Laurenz Albe <laurenz.albe@cybertec.at>)
Список 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 по дате отправления:

Предыдущее
От: Thomas Guyot
Дата:
Сообщение: Re: How to post to this mailing list from a web based interface
Следующее
От: Tom Lane
Дата:
Сообщение: Re: pg_stat_user_tables.n_mod_since_analyze persistence?