| From: | Jeff Frost <jeff(at)pgexperts(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
| Cc: | Soni M <diptatapa(at)gmail(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Postgres Replaying WAL slowly |
| Date: | 2014-06-30 19:25:30 |
| Message-ID: | F3E1168D-8D49-407E-A8B7-B3ED81C93DCB@pgexperts.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Jun 30, 2014, at 12:17 PM, Jeff Frost <jeff(at)pgexperts(dot)com> wrote:
>>
>> already is quite helpful.
>>
>> What are you doing on that system? Is there anything requiring large
>> amounts of access exclusive locks on the primary? Possibly large amounts
>> of temporary relations?
>
>
> The last time we did a 100% logging run, the peak temp table creation was something like 120k/hr, but the replicas seemed able to keep up with that just fine.
>
Sampling pg_locks on the primary shows ~50 locks with ExclusiveLock mode:
mode | count
--------------------------+-------
AccessExclusiveLock | 11
AccessShareLock | 2089
ExclusiveLock | 46
RowExclusiveLock | 81
RowShareLock | 17
ShareLock | 4
ShareUpdateExclusiveLock | 5
Seems to be relatively consistent. Of course, it's hard to say what it looked like back when the issue began.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2014-06-30 19:32:30 | Re: Postgres Replaying WAL slowly |
| Previous Message | Jeff Frost | 2014-06-30 19:17:05 | Re: Postgres Replaying WAL slowly |