Re: Hot Standby Conflict on pg_attribute
От | Tom Lane |
---|---|
Тема | Re: Hot Standby Conflict on pg_attribute |
Дата | |
Msg-id | 14290.1557517255@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Hot Standby Conflict on pg_attribute (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Hot Standby Conflict on pg_attribute
|
Список | pgsql-general |
Andres Freund <andres@anarazel.de> writes: > On 2019-05-09 13:03:50 -0700, Erik Jones wrote: >> The question then is: Why would these user queries be waiting on an >> AccessShare lock on pg_attribute? > Queries that access a table for the *first* time after DDL happened > (including truncating the relation), need an AccessShareLock on > pg_attribute (and pg_class, pg_index, ...) for a short time. Also, it seems likely that what's really triggering the issue is autovacuum on pg_attribute trying to truncate off empty pages in pg_attribute (after a bunch of dead rows were generated there by DDL activity). That requires exclusive lock on pg_attribute, which would propagate down to the standby. regards, tom lane
В списке pgsql-general по дате отправления: