Re: Redesigning checkpoint_segments - Mailing list pgsql-hackers

From Joshua D. Drake
Subject Re: Redesigning checkpoint_segments
Date
Msg-id 51B02C21.9010203@commandprompt.com
Whole thread Raw
In response to Re: Redesigning checkpoint_segments  (Daniel Farina <daniel@heroku.com>)
Responses Re: Redesigning checkpoint_segments  (Peter Geoghegan <pg@heroku.com>)
List pgsql-hackers
On 6/5/2013 11:09 PM, Daniel Farina wrote:
> Instead of "running out of disk space PANIC" we should just write to an
> emergency location within PGDATA and log very loudly that the SA isn't
> paying attention. Perhaps if that area starts to get to an unhappy place we
> immediately bounce into read-only mode and log even more loudly that the SA
> should be fired. I would think read-only mode is safer and more polite than
> an PANIC crash.
>
> I do not think we should worry about filling up the hard disk except to
> protect against data loss in the event. It is not user unfriendly to assume
> that a user will pay attention to disk space. Really?
> Okay, then I will say it's user unfriendly, especially for a transient
> use of space, and particularly if there's no knob for said SA to
> attenuate what's going on.  You appear to assume the SA can lean on
> the application to knock off whatever is going on or provision more
> disk in time, or that disk is reliable enough to meet one's goals.  In
> my case, none of these precepts are true or desirable.
I have zero doubt that in your case it is true and desirable. I just 
don't know that it is a positive solution to the problem as a whole. 
Your case is rather limited to your environment, which is rather limited 
to the type of user that your environment has. Which lends itself to the 
idea that this should be a Heroku Postgres thing, not a .Org wide thing.

Sincerely,

JD




pgsql-hackers by date:

Previous
From: Harold Giménez
Date:
Subject: Re: Redesigning checkpoint_segments
Next
From: Peter Geoghegan
Date:
Subject: Re: Redesigning checkpoint_segments