[ postfixadmin-Bugs-2986880 ] Quta's stored as integers, should be bigint.

[SourceForge.net <no...@so...>]

Bugs item #2986880, was opened at 2010-04-14 01:21
Message generated for change (Tracker Item Submitted) made by n0d3
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2986880&group_id=191583

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Database
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: oliver (n0d3)
Assigned to: Nobody/Anonymous (nobody)
Summary: Quta's stored as integers, should be bigint.

Initial Comment:
Quta's in the database may become to small soon. Currently quota's can be stored as any integer, and be multiplied externally. Thus having a quota of '10' could mean anything from 10 bytes, to 10GB depending on what multiplication factor is used in postfixadmin's config.inc.php.

Postfix itself talks to the table via a select statement, that's just how it does that, and currently, with postfix the following query would be sent to postfix;
postfix=> select quota from mailbox;                   
 quota                                                                          
-------                                                                         
    10                                                                          
(1 row)  

Doing the same external multiplication trick works, as long as it stays under 2^32, the maximum size for an integer; 
So for example:
postfix=> select (quota *1024 *1024) from mailbox;      
 ?column?                                                                       
----------                                                                      
 10485760                                                                       
(1 row)    
Doesn't cause any issue really, so where is the problem?

Well let's say this user is allowed to have some absurd quota, say 10GB. (Remember, Google already offers 1GB quotas and 2GB quotas exist for webmail providers. Having certain users with 10GB shouldn't be all that awkward.
Trying a 10GB quota however fails horribly.
postfix=> select (quota *1024 *1024 *1024) from mailbox;
                                                                                
ERROR:  integer out of range

Changing the quota per user field from an Integer to a bigint solves the issue;
ALTER TABLE mailbox ALTER quota TYPE bigint;
postfix=> select (quota *1024 *1024 *1024) from mailbox;
  ?column?                                                                      
-------------
 10737418240
(1 row)

In conclusion, this means quota's would have never worked if they where bigger then the type of the table, so using external multipliers would have only worked for anything not dependent on the SQL query (which postfix is). Actually, having an external multiplier is useless, though it allows for pretty printing. There could be many reasons actually been thought of to store the quota in bytes actually. Changing the type to bigint actually allows for absurd high quota's 9223372036854774784 or 8Exabyte on a per user level is maybe to high (even in a million years from now, I don't see anybody using 8Exabyte mailboxes) but could pose a problem, far far in the future for quota for domains or maxquota for all domains combined?

So I would recommend, drop external multipliers, store quota's in bytes, pretty print them where needed and convert integers to bigints where needed (e.g. quota for per user, domain etc).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2986880&group_id=191583