References: 
 <CA+OQrzhdtpC-9enDpY_PTue3_eh9xxmP-z51fJHFqezvhJ-9Nw@mail.gmail.com>
 <CAJghg4+y5NcvjfJO+Ynad-5NcuHHOUOgFpUEP=fLA3WTgGAoCw@mail.gmail.com>
 <CAHyXU0w+haLQ2UdU_XjyiEPnC_Xp24QM4QjNYXFXQhtkvdSsgA@mail.gmail.com>
 <CA+OQrzhBziFavzH==iqrJegR5Us6q7EvbopkQAWJV9f-UYVthQ@mail.gmail.com>
 <1408399307.93048.YahooMailNeo@web122304.mail.ne1.yahoo.com>
 <12486.1408404273@sss.pgh.pa.us>
 <1408448332.31825.YahooMailNeo@web122302.mail.ne1.yahoo.com>
 <CA+OQrzh1fOgZ7WQDm+hwNh-32ONk5xvf7L5cbiz=9ycb0PdzcA@mail.gmail.com>
Message-ID: <1408466441.59082.YahooMailNeo@web122304.mail.ne1.yahoo.com>
Date: Tue, 19 Aug 2014 09:40:41 -0700
From: Kevin Grittner <kgrittn@ymail.com>
Reply-To: Kevin Grittner <kgrittn@ymail.com>
Subject: Re: query against pg_locks leads to large memory alloc
To: Dave Owens <dave@teamunify.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Merlin Moncure <mmoncure@gmail.com>,
 Matheus de Oliveira <matioli.matheus@gmail.com>,
 postgres performance list <pgsql-performance@postgresql.org>
In-Reply-To: 
 <CA+OQrzh1fOgZ7WQDm+hwNh-32ONk5xvf7L5cbiz=9ycb0PdzcA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

Dave Owens <dave@teamunify.com> wrote:

> 1358 tables
> 1808 indexes

Hmm, that's not outrageous.=A0 How about long-running transactions?
Please check pg_stat_activity and pg_prepared_xacts for xact_start
or prepared (respectively) values older than a few minutes.=A0 Since
predicate locks may need to be kept until an overlapping
transaction completes, a single long-running transaction can bloat
the lock count.

Also, could you show use the output from?:

=A0 SELECT version();

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


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