Received: from malur.postgresql.org ([217.196.149.56])
 by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from
 <pgsql-performance-owner+M51882=pgsql-performance-ar@postgresql.org>)
 id 1X1hJi-0001Yh-4P
 for pgsql-performance@arkaria.postgresql.org; Mon, 30 Jun 2014 19:32:42 +0000
Received: from localhost ([127.0.0.1] helo=postgresql.org)
 by malur.postgresql.org with smtp (Exim 4.80) (envelope-from
 <pgsql-performance-owner+M51882=pgsql-performance-ar@postgresql.org>)
 id 1X1hJh-0002kY-29
 for pgsql-performance@arkaria.postgresql.org; Mon, 30 Jun 2014 19:32:41 +0000
Received: from makus.postgresql.org ([2001:4800:1501:1::229])
 by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256)
 (Exim 4.80) (envelope-from <tgl@sss.pgh.pa.us>) id 1X1hJf-0002kR-Po
 for pgsql-performance@postgresql.org; Mon, 30 Jun 2014 19:32:39 +0000
Received: from sss.pgh.pa.us ([66.207.139.130])
 by makus.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256)
 (Exim 4.80) (envelope-from <tgl@sss.pgh.pa.us>) id 1X1hJc-00085D-Ky
 for pgsql-performance@postgresql.org; Mon, 30 Jun 2014 19:32:37 +0000
Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1])
 by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id s5UJWUGH020301;
 Mon, 30 Jun 2014 15:32:30 -0400
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jeff Frost <jeff@pgexperts.com>
cc: Andres Freund <andres@2ndquadrant.com>, Soni M <diptatapa@gmail.com>,
 Heikki Linnakangas <hlinnakangas@vmware.com>,
 pgsql-performance@postgresql.org
Subject: Re: Postgres Replaying WAL slowly
In-reply-to: <F3E1168D-8D49-407E-A8B7-B3ED81C93DCB@pgexperts.com>
References: 
 <CAAMgDXm5Y9QPELKvCGBrFvPcuR0ENVA1tEYRcazhDSxs6xnX5w@mail.gmail.com>
 <53AFCEE3.4080009@vmware.com>
 <CAAMgDXnKknBDk+Zb3BXau1cKV7y1A0vd9CJpX=vkSTXVGBrZwA@mail.gmail.com>
 <53B10C4C.8090701@vmware.com>
 <CAAMgDX=c8_6tutCDNiu38Z4wguKMGbhqznVNyMiOC5PZBpn1Fw@mail.gmail.com>
 <53B18CE0.4060501@vmware.com> <20140630171416.GK21422@awork2.anarazel.de>
 <CAAMgDXnT8cQbwxcNXfFKONrRVAKoGhR-3FWYSX_5gJcFrEMPMQ@mail.gmail.com>
 <8DA8C140-818D-4184-AAE6-CA37278B983C@pgexperts.com>
 <20140630183908.GT26930@awork2.anarazel.de>
 <0A7B96D4-DB10-49A8-A268-F28960F2E137@pgexperts.com>
 <F3E1168D-8D49-407E-A8B7-B3ED81C93DCB@pgexperts.com>
Comments: In-reply-to Jeff Frost <jeff@pgexperts.com>
 message dated "Mon, 30 Jun 2014 12:25:30 -0700"
Date: Mon, 30 Jun 2014 15:32:30 -0400
Message-ID: <20300.1404156750@sss.pgh.pa.us>
X-Pg-Spam-Score: -1.9 (-)
List-Archive: <http://archives.postgresql.org/pgsql-performance>
List-Help: <mailto:majordomo@postgresql.org?body=help>
List-ID: <pgsql-performance.postgresql.org>
List-Owner: <mailto:pgsql-performance-owner@postgresql.org>
List-Post: <mailto:pgsql-performance@postgresql.org>
List-Subscribe: <mailto:majordomo@postgresql.org?body=sub%20pgsql-performance>
List-Unsubscribe: 
 <mailto:majordomo@postgresql.org?body=unsub%20pgsql-performance>
X-Mailing-List: pgsql-performance
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

Jeff Frost <jeff@pgexperts.com> writes:
> 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

That's not too helpful if you don't pay attention to what the lock is on;
it's likely that all the ExclusiveLocks are on transactions' own XIDs,
which isn't relevant to the standby's behavior.  The AccessExclusiveLocks
are probably interesting though --- you should look to see what those
are on.

			regards, tom lane


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance