Re: Dumping a database that is not accepting commands? - Mailing list pgsql-admin

From Natalie Wenz
Subject Re: Dumping a database that is not accepting commands?
Date
Msg-id 2EE7C659-6FA5-409D-8401-3F8A22E9DF3A@ebureau.com
Whole thread Raw
In response to Re: Dumping a database that is not accepting commands?  (bricklen <bricklen@gmail.com>)
List pgsql-admin
No…  the shared_buffers value is just a legacy value that never got changed (the shmmax value in sysctl is still 1073741824).  When I set up the new database, I set the shared_buffers to 25% of system memory, so 12GB. (And since the new database is on 9.3, I didn't have to adjust the sysctl value for shmmax! Happy day!)

We used to have maintenance_work_mem set to something smaller, but we bumped that up after…<coughs>… the last time this database shut itself down to avoid wraparound in March 2012. We were hoping that would help speed the recovery at that time. Not sure if it did, but we left it that way afterward anyway.


On Sep 17, 2013, at 2:02 PM, bricklen <bricklen@gmail.com> wrote:

On Tue, Sep 17, 2013 at 9:48 AM, Natalie Wenz <nataliewenz@ebureau.com> wrote:
 maintenance_work_mem            | 10GB
 shared_buffers                  | 128MB

maintenance_work_mem seems pretty high, and shared_buffers seems really low.  Out of curiousity, were those set as a product of internal testing which determined those were effective settings?


pgsql-admin by date:

Previous
From: bricklen
Date:
Subject: Re: Dumping a database that is not accepting commands?
Next
From: Natalie Wenz
Date:
Subject: Re: Dumping a database that is not accepting commands?