Re: SOC & user quotas

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: "Sergey E(dot) Koposov" <math(at)sai(dot)msu(dot)ru>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, pgsql-hackers(at)postgresql(dot)org, Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>
Subject: Re: SOC & user quotas
Date: 2007-03-01 21:45:34
Message-ID: 17193.1172785534@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jeff Davis <pgsql(at)j-davis(dot)com> writes:
> 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?

The reason it appears not to work now is that the code is deliberately
set up not to check permissions on the database's default tablespace, on
the theory that if you have regular CREATE permissions in the database
then you probably are supposed to be able to create things. However,
if you want to restrict someone to a filesystem-limited tablespace, you
can surely make that tablespace be the default for their database.
This would make the quota include system catalogs as well as "user"
tables, which seems to me a good idea anyway because it's not hard for a
user to bloat the system catalogs. (The fact that pg_largeobject is a
communal table makes per-user quotas useless for BLOB users already.)

Now if you want quota-limited users to share a database with
not-quota-limited users, this doesn't work too well. The non-limited
users can surely be set up with access to a non-default tablespace,
but if the system catalogs hit the quota limit then everyone's gonna
be unhappy.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2007-03-01 22:06:34 Re: SOC & user quotas
Previous Message Jeff Davis 2007-03-01 21:21:34 Re: SOC & user quotas