Hello hackers,

I was starting to think about next SOC and the project for it. And for a long time I wanted to implement the user quotas in PG. So, I'll try to explain my understanding of the implementation, and I'll be happy to hear any comments, objections, or pointings to my misunderstanding. This is very first very rough idea, but I still would like to hear whether it contains some obvious flaws...

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.

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. If I understand correctly, only functions like mdcreate & mdextend really change the size of the user relations (I don't consider things like WAL, and I don't think it should be subject for quota). And it seems to me, that the machinery of smgr/md is moreless enough to control the space occupied by the relations (within some 1 block size precision).

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. As soon as this number is equal to zero, all the mdcreate, mdextend functions shouldn't do anything but return the error. I don't know, but I hope these functions won't be invoked if the user will do DELETE and/or VACUUM to recover the space ? Also, I'm not completely sure that refusing the call of the mdextend function in the case of quota excess won't lead to any corruption ? (in the case of Btree splits for example ).

Any comments ?
Thank you.


Sergey E. Koposov
Max Planck Institute for Astronomy/Cambridge Institute for Astronomy/Sternberg 
Astronomical Institute
Tel: +49-6221-528-349
Web: http://lnfm1.sai.msu.ru/~math

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
      choose an index scan if your joining column's datatypes do not

Reply via email to