simultaneous checking

[Ivan Kalik]

> Phil Mayers wrote:
>> I must admit, I'd assumed someone had a specific reason for the field
>> sizes being what they are, and didn't want to pre-empt them. But if
>> there isn't such a reason, I'll knock one up.
>
>   Nothing depends on the fields being specific sizes.  If it's possible
> to make them "large enough", that's a good patch.

Nothing in freeradius. But on the database side? Radacct is a big chunk as
it is. Most people keep at least 3 months worth of data and than can be
quite a few GB. There is significant impact on database performance at the
time of daily backup. Proposed changes would increase radacct size by
10-20%. That's a few more minutes of poorly responsive database.
Increasing field sizes to 250 characters when huge majority of people
would do fine with only one tenth of that field is not a very good design
solution. Perhaps adding a second schema where these fields are maxed up
(large_fields_schema.sql)?

PS. I must appologize, it was not my intention to imply that if your
equipment generates large ids admin is insane by default. My comments were
related to that specific case where admin shot himself in the foot by
appending text to basic id causing database filed overflow.

Ivan Kalik
Kalik Informatika ISP