Hi, I'm having some problems with Alive messages that follow immediately after Start messages. Sometimes this causes two entries with the same acctuniqeid to be entered into the database, the only thing separating the two being a few hundreds of a second on the acctstarttime field. I find this behaviour rather annoying, and as I mentioned in an earlier mail, that was confirmed by Alan DeKok, it is cause by the following: 1) Receives a Start packet and inserts a new entry/session in the db 2) Receives Alive packet _immediately_ after the Start packet, and queries the database to see if the unique-session-id already exists. 3) The query doesn't return anything, since postgresql hasn't had time to complete the INSERT-query for the Start packet, and accounting_update_query_alt is thus run. I'm not at all experienced with databases, but I was thinking I could lock the accounting table while inserting the Start message, so that the query in pnt. 2 could not be performed until the Insert in pnt. 1 is finished. Wouldn't this elminate the problem in pnt. 3? How does freeradius react to a situation like this.. does it keep trying to perform the SELECT query in 2 until it succeds, or is the Alive packed just dropped? If the latter is the case, does anyone here know if I can make postgresql queue requests that get blocked because of the lock? Anyone else had this problem, and if so, how did you get around it, if you got around it at all? Any pointers would be highly appreciated :) Regards, Roger Kristiansen