#192 Quta's stored as integers, should be bigint.

closed-wont-fix
nobody
Database (41)
5
2010-05-18
2010-04-14
oliver
No

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).

Discussion

  • Christian Boltz

    Christian Boltz - 2010-05-18

    As long as you use one of the usual multipication factors in config.inc.php ('1024000' or '1048576'), the mailbox quota is already stored in bytes.

    Also the quota fields are already bigint - IIRC already in the 2.3 release, for sure in SVN.

    Remaining issue: the domain-level quota ($CONF(maxquota)) is stored in MB instead of bytes. However, that's just used internally in postfixadmin, and changing it to bytes would probably cause more harm than good on upgrade.

    Therefore:
    - closing as "out of date" for the bigint field type because this is already implemented
    - closing as "wontfix" for changing domain-level maxquota to bytes instead of MB

    If you disagree or still have "small" integer quota fields with 2.3 or the upcoming 2.3.1 release (don't forget to run setup.php after upgrade), feel free to reopen this ticket ;-)

     
  • Christian Boltz

    Christian Boltz - 2010-05-18
    • status: open --> closed-wont-fix
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks