| From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Jeff Mcdowell <Jeff(dot)Mcdowell(at)panerabread(dot)com>, "pgsql-general(at)postgreSQL(dot)org" <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: Vacuum of large tables causing replication delays to hot standby |
| Date: | 2016-04-30 17:45:42 |
| Message-ID: | 20160430174542.GA204034@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Tom Lane wrote:
> Jeff Mcdowell <Jeff(dot)Mcdowell(at)panerabread(dot)com> writes:
> > 95% of the time, the delay is only microseconds. But we have discovered that whenever the master does an auto vacuum of a large table, the transaction replay delay can climb is high as 1 hour. These delays dont seem to correlate with any particular queries that are running against the master or the standby, and the delay only subsides when the vacuum completes.
>
> What PG version might this be?
This sounds related to
commit 3e4b7d87988f0835f137f15f5c1a40598dd21f3d
Author: Simon Riggs <simon(at)2ndQuadrant(dot)com>
AuthorDate: Sun Apr 3 17:46:09 2016 +0100
CommitDate: Sun Apr 3 17:46:09 2016 +0100
Avoid pin scan for replay of XLOG_BTREE_VACUUM in all cases
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Mcdowell | 2016-04-30 19:03:02 | Re: Vacuum of large tables causing replication delays to hot standby |
| Previous Message | Tom Lane | 2016-04-30 17:37:13 | Re: Vacuum of large tables causing replication delays to hot standby |