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
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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?

Regards,
Jeff Davis

In response to

Browse pgsql-hackers by date

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