On Tue, Oct 11, 2011 at 8:50 PM, Scott Marlowe wrote:
> On Tue, Oct 11, 2011 at 5:00 PM, Sean Laurent wrote:
>> As much as I would like Postgres to withstand a 2 second outage, I
>> don't honestly care. I'd just like to figure out whether I'm looking
>> at so
tem - it's under load, but not a
tremendously high load. During our busier times we average something
in the neighborhood of 300-400 transactions per second, which just
doesn't seem like that much.
As much as I would like Postgres to withstand a 2 second outage, I
don't honestly ca
On Fri, Oct 7, 2011 at 12:36 AM, Tom Lane wrote:
>
> Sean Laurent writes:
> > We've been running into a particularly strange problem that I'm trying to
> > better understand. The super short version is that our application servers
> > lose their connection t
On Mon, Oct 10, 2011 at 8:09 AM, Craig Ringer wrote:
> On 10/07/2011 01:21 AM, Sean Laurent wrote:
>> Within a few seconds of the backup, our application servers start
>> throwing exceptions that indicate the database connection was closed.
>> Meanwhile, Postgres still show
time. The
backups were running every hour, but we have only seen the app servers crash
5-10 times over the course of a month.
Has anyone encountered anything like this? Do any of these steps have
ramifications that I'm not considering? Especially something that might
explain the app server failure?
Thanks.
Sean Laurent
Director of Operations
StudyBlue, Inc.
On Sun, Feb 27, 2011 at 1:04 PM, Jens Wilke wrote:
> On Sonntag, 27. Februar 2011, Sean Laurent wrote:
>
> > Unfortunately, most queries against the hot standby fail. Worse
> > yet, pg_dump fails:
> ...
> > I'm not entirely certain I understand why I'm seeing
I have a hot-standby instance setup using Postgres 9.0.1 with streaming
replication against a 9.0.1 master. On the master, I have the following set
in the postgresql.conf:
checkpoint_segments = 3
checkpoint_timeout = 1min
checkpoint_completion_target = 0.5
max_wal_senders = 3
wal_sender_delay = 20
