"Sergey E. Koposov" <math@sai.msu.ru> writes:
> 1) The main idea is to implement the per-user quota (not per tablespace
> for example). So, during the creation of the new user some quota can be
> specified, and after that the size of all the relations *owned* by that
> user should be limited by that number.
This seems impractical as stated; there is no way to determine what a
user owns in some other database. Possibly you could do it if the quota
were both per-user and per-database.
> 2) I looked into the code, and from my understanding, the main part of the
> code which should be affected by the quotas is storage/smgr/md.c.
md.c is too low level to do catalog accesses and thus too low level to
know who owns what.
> 3) How the quota should be controlled: I think, that generally, for all
> the users which have quotas, the shared memory should contain the number
> of blocks left from the quota. And each backend extending or truncating
> the relations owned by the user should appropriately change that number of
> blocks left in the shared memory.
What will you do with ALTER TABLE OWNER? What if such a command is
rolled back? (Likewise for some other commands such as TRUNCATE, or
even just DROP TABLE.) What if there are too many users to fit in your
(necessarily fixed size) shared memory area? What sort of contention
will there be for access to this area?
regards, tom lane