Skip site navigation (1) Skip section navigation (2)

Re: SOC & user quotas

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Sergey E(dot) Koposov" <math(at)sai(dot)msu(dot)ru>, pgsql-hackers(at)postgresql(dot)org, Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>
Subject: Re: SOC & user quotas
Date: 2007-03-01 22:37:04
Message-ID: 1172788624.13722.114.camel@dogma.v10.wvs (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Thu, 2007-03-01 at 14:13 -0800, Joshua D. Drake wrote:
> Andrew Dunstan wrote:
> > Jeff Davis wrote:
> >>
> >> If we allowed an admin to revoke CREATE from the pg_default tablespace,
> >> then anyone who needed that feature could limit people to their own
> >> tablespace (at which point it's the filesystem's job to limit their
> >> usage). Is there some reason that we can't do this now?
> >>
> >>   
> > 
> > 
> > Hitting a file system quota limit is likely to bring you down pretty
> > hard, isn't it?
> Yes, and likely corrupt the database.

Is it possible to make the database safe in this case? I can see why it
would be difficult to handle pg_xlog filling up (or for that matter
pg_log), but couldn't any other area be turned into just a simple ERROR?

pg_xlog is cluster-wide, so even if you had the databases in separate
quota-limited areas, that wouldn't mean pg_xlog would fill up.

If it's possible to allow disk-is-full to become a simple error, that
might satisfy this request without much effort. If it is a lot of
effort, then I retract my suggestion.

By the way, is there some good documentation about what actually happens
in different cases when the disk is full? I treat it as "never let this
happen" and I don't really know what to expect if it did happen.

	Jeff Davis

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2007-03-01 22:53:08
Subject: Re: SOC & user quotas
Previous:From: Andrew DunstanDate: 2007-03-01 22:35:09
Subject: Re: SOC & user quotas

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group