| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Jeff Frost <jeff(at)pgexperts(dot)com> |
| Cc: | Andres Freund <andres(at)2ndquadrant(dot)com>, Matheus de Oliveira <matioli(dot)matheus(at)gmail(dot)com>, Soni M <diptatapa(at)gmail(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, pgsql-performance <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Postgres Replaying WAL slowly |
| Date: | 2014-06-30 20:39:44 |
| Message-ID: | 21474.1404160784@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Jeff Frost <jeff(at)pgexperts(dot)com> writes:
> On Jun 30, 2014, at 1:15 PM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
>> So these are probably relations created in uncommitted
>> transactions. Possibly ON COMMIT DROP temp tables?
> That would make sense. There are definitely quite a few of those being used.
Uh-huh. I doubt that the mechanism that handles propagation of
AccessExclusiveLocks to the standby is smart enough to ignore locks
on temp tables :-(
> Another item of note is the system catalogs are quite bloated:
> Would that cause the replica to spin on StandbyReleaseLocks?
AFAIK, no. It's an unsurprising consequence of heavy use of short-lived
temp tables though.
So it seems like we have a candidate explanation. I'm a bit surprised
that StandbyReleaseLocks would get this slow if there are only a dozen
AccessExclusiveLocks in place at any one time, though. Perhaps that
was a low point and there are often many more?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Frost | 2014-06-30 20:46:05 | Re: Postgres Replaying WAL slowly |
| Previous Message | Jeff Frost | 2014-06-30 20:21:08 | Re: Postgres Replaying WAL slowly |