| From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
|---|---|
| To: | dimitri(at)2ndQuadrant(dot)fr |
| Cc: | pgsql-bugs(at)postgresql(dot)org |
| Subject: | Re: BUG #13895: Hot Standby locked replaying auto vacuum against pg_catalog.pg_statistics |
| Date: | 2016-01-28 12:53:51 |
| Message-ID: | 20160128125351.GA728572@alvherre.pgsql |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
dimitri(at)2ndQuadrant(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dimitri Fontaine | 2016-01-28 13:19:15 | Re: BUG #13895: Hot Standby locked replaying auto vacuum against pg_catalog.pg_statistics |
| Previous Message | listas | 2016-01-28 12:45:39 | BUG #13896: Current docs says 'worker_spi' is a contrib |