Received: from maia.hub.org (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 55EB1635895 for ; Tue, 9 Mar 2010 11:03:29 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 90276-03 for ; Tue, 9 Mar 2010 15:03:18 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-yw0-f180.google.com (mail-yw0-f180.google.com [209.85.211.180]) by mail.postgresql.org (Postfix) with ESMTP id DF06F635958 for ; Tue, 9 Mar 2010 11:03:18 -0400 (AST) Received: by ywh10 with SMTP id 10so607915ywh.20 for ; Tue, 09 Mar 2010 07:03:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=i7W4zde6caQZrnZIqDNp0l2Mt7iwh1GLyBfhKrSHJe0=; b=vumSUx9wzDUgdApoqMvD8Ir1w6HEp8V/Cqseak/iKIUW0DNvkYtiWfbhVla+jGFDla WqCuTBzk5kqm/YD72ZYCuw2EQNLiCpsfGogpIRyIAZjB2Pq9lO+MBUyJVfHSeiGFY/Y1 vd3gEJCzCDRFM67s7du/pNgxkXVzV78DNqT5k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=GKoJ6ta5GrfG2FsFLutBVDw4NooEOuN6DskgFyPDdj19HEcBca+I97hr8vxhGaCrdA GUFkcv91MnLJDm5KuIYkRU/O9n9gYPZBCmxYeuSopa/qNXCxqv5+ayzVN2hoLPXXQQ8q tafeNSVPuAHqoaChmYtN1tDEjoTrF3PjZ8cVs= MIME-Version: 1.0 Received: by 10.90.16.12 with SMTP id 12mr170021agp.46.1268146996604; Tue, 09 Mar 2010 07:03:16 -0800 (PST) In-Reply-To: <919b7db61003090527k3c8ad4cw84b70e55bd15cd1e@mail.gmail.com> References: <919b7db61003090138j6da56dffu5e0ddd4276168b48@mail.gmail.com> <919b7db61003090527k3c8ad4cw84b70e55bd15cd1e@mail.gmail.com> Date: Tue, 9 Mar 2010 10:03:16 -0500 Message-ID: Subject: Re: Out of shared memory in postgres 8.4.2 and locks From: Merlin Moncure To: Vidhya Bondre Cc: pgsql-performance@postgresql.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-2.599 tagged_above=-10 required=5 tests=BAYES_00=-2.599 X-Spam-Level: X-Archive-Number: 201003/93 X-Sequence-Number: 37918 On Tue, Mar 9, 2010 at 8:27 AM, Vidhya Bondre wrote= : >> >> are you using the same postgresql.conf? =A0have you created more >> partitions? =A0using advisory locks? > > Yes we are using same conf files. In a week we create around 5 partitions= . > We are not using advisory locks >> >> In any event, increase the max_locks_per_transaction setting and >> restart the database. > > > Currently the value of max_locks_per_transaction is 64 modifying it to 96 > works. > Have a couple of questions > 1] As and when we add partitions will we have to increase this parameter = ? > 2] will we have to consider any othe parameter twick while increasing thi= s > one? If you are doing 'in transaction' operations that involve a lot of tables this figure has to be bumped, sometimes significantly. You might be tempted just crank it, and be done with this problem. If so, be advised of what happens when you do: *) more shared memory usage (make sure you have memory and shared_buffers is appropriately set). however for what you get the usage is relatively modest. *) anything that scans the entire in memory lock table takes longer in relationship to this .conf value. AFAIK, the only noteworthy thing that does this is the pg_locks view. The 'other' big shared memory tradeoff you historically had to deal with, the fsm map, is gone in 8.4. merlin