Re: BUG #13895: Hot Standby locked replaying auto vacuum against pg_catalog.pg_statistics
От | Alvaro Herrera |
---|---|
Тема | Re: BUG #13895: Hot Standby locked replaying auto vacuum against pg_catalog.pg_statistics |
Дата | |
Msg-id | 20160128125351.GA728572@alvherre.pgsql обсуждение исходный текст |
Ответ на | BUG #13895: Hot Standby locked replaying auto vacuum against pg_catalog.pg_statistics (dimitri@2ndQuadrant.fr) |
Ответы |
Re: BUG #13895: Hot Standby locked replaying auto vacuum against pg_catalog.pg_statistics
Re: BUG #13895: Hot Standby locked replaying auto vacuum against pg_catalog.pg_statistics |
Список | pgsql-bugs |
dimitri@2ndQuadrant.fr wrote: > > I witnessed a case where I had no time to extract information about it, so > it's all from memory, sorry about that. > > We had several Hot Standby nodes in 9.3.x used for load balancing read only > queries. All queries were stuck, and pg_locks showed they were refused a > lock against pg_catalog.pg_statistics. My WAG is that this is related to the standby replaying the AccessExclusive lock obtained to truncate pg_statistics. That seems consistent with the presented symptoms. I would have assumed that the actual truncation shouldn't take a particularly long time, so user processes on the standby wouldn't be locked for long enough to cause visible trouble. Maybe the table was originally very bloated and a lot of pages got removed, leading the replay process to take some time. It is strange that it would be locked for long enough to allow for manually querying pg_locks and pg_stat_activity. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-bugs по дате отправления: