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

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 (view raw or flat)
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

pgsql-hackers by date

Next:From: Andrew DunstanDate: 2007-03-01 22:06:34
Subject: Re: SOC & user quotas
Previous:From: Jeff DavisDate: 2007-03-01 21:21:34
Subject: Re: SOC & user quotas

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