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

Re: SOC & user quotas

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: "Sergey E(dot) Koposov" <math(at)sai(dot)msu(dot)ru>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers(at)postgresql(dot)org, Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>
Subject: Re: SOC & user quotas
Date: 2007-03-02 01:26:41
Message-ID: 1172798801.13722.163.camel@dogma.v10.wvs (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Fri, 2007-03-02 at 03:31 +0300, Sergey E. Koposov wrote:
> > So it seems like we already have a solution to quotas at the database
> > level.
> I still  don't understand how FS quotas can help with DB quotas. ..
> All the FS quotas are setup for limiting  the space for specific user and 
> specific mount point. AFAIK They do not allow to limit the space in one 
> directory. And since all the PG tablespaces will be owned by postgres 
> user, I dont think the FS quotas can do the job.

Some filesystems help you more than others. In ZFS you can create a
filesystem that uses a pre-existing storage pool and set a quota on that
filesystem, and then mount it for the user that you want. In effect,
it's basically a directory quota (no space reservation necessary, but a
space limit).

For the project you're working on, can you just set the default
tablespaces to be restricted-size areas for the scientists? If you trust
the scientists setting their default tablespace should be enough, and
they don't need to be in a separate database.

Or if you don't trust the scientists, could you use a separate database
and the scientists could query with something like dblink?

	Jeff Davis

In response to

pgsql-hackers by date

Next:From: Jim C. NasbyDate: 2007-03-02 03:30:49
Subject: Re: Revitalising VACUUM FULL for 8.3
Previous:From: Sergey E. KoposovDate: 2007-03-02 01:22:09
Subject: Re: SOC & user quotas

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