On Fri, 2006-02-24 at 09:48 -0600, Kevin Grittner wrote:
> >>> On Fri, Feb 24, 2006 at 9:34 am, in message
> <1140795253.5092.122.camel@home>,
> Rod Taylor <pg@rbt.ca> wrote:
> >
> > You don't need to know the free diskspace in real time. A 2 minute
> old
> > value is probably just as good.
>
> Not really, this sort of monitoring has kept us from crashing under our
> old database product when a poorly written query starts filling
> available space by populating a temporary table. A green light turns
I see. It is annoying that you cannot easily (takes a patch to PG
sources) segregate users temporary workspaces into per-user tablespaces
with filesystem quotas.
PostgreSQL seems to deal with out of diskspace situations pretty well
when it impacts a tablespace (global stuff like WAL or subtransactions
have issues -- but they grow slowly) as far as only interrupting service
for the individual actions that ran out.
You may wish to look at funding toggles that can configure the maximum
memory usage and maximum temporary diskspace (different tablespaces with
filesystem quotas) on a per user basis similar to the statement_timeout
limitations in place today.
I'm curious as to how you monitor for total transaction time length to
ensure that vacuum is able to do its thing, particularly when the
transaction is active (not IDLE).
--
