[Serusers] Over-long fields can crash SER with PostgreSQL

We are using SER with the PostgreSQL module, so that SER and our Asterisk PSTN gateway and voice mail system can use the same back-end database for user records. (Anyone who's interested in how we did this, let me know -- it's still a little shaky, but it pretty much works.) Recently we have encountered a problem: it seems that if any database error occurs, SER hangs or crashes. We have so far been able to mostly work around these conditions by being Really Careful with the database, but it is a little unsettling. The database schema we're working from is practically identical to the MySQL schema that ships with SER. Notably for this problem the lengths of all CHARACTER VARYING fields are the same. The User-Agent field is CHARACTER VARYING(50), for instance. So ... today boss got a copy of Xten's "eyeBeam" software, set it up to register to our SER ... and SER promptly locked up. I looked in the PostgreSQL database log and found this: Feb 10 13:39:32 mabell postgres[13058]: [267] ERROR: value too long for type character varying(50) Whoops. SER tried to insert eyeBeam's User-Agent data, PostgreSQL returned a data integrity error, and SER went bye-bye. So I did a little ALTER TABLE and adjusted the field to length 128 ... then put this in ser.cfg: # Disallow long user-agent if (search("^User-Agent: .{100,}") ) { log(1, "LOG: User agent too long\n"); sl_send_reply("479", "User agent too long!"); break; }; But this is obviously a kludge ... and doesn't fix the problem of one of the *other* fields being over-long. Anyone have any thoughts on this? Robustness patches for the PostgreSQL module or usrloc? Better ser.cfg workarounds to protect the world from malformed or over-long SIP header fields? Should I just change all the database fields to TEXT instead of CHARACTER VARYING(whatever) ? -- Karl A. Krueger <kkrueger(a)whoi.edu> Network Security -- Linux/Unix Systems Support -- Etc. Woods Hole Oceanographic Institution