Hi, I'm in the process of getting my first 3.0.2 instance to production level. Now that I've moved eduroam accounting handling into production (rlm_sql_null instance), I see something that looks like a concurrent write of sorts to me. I have this in my file: UPDATE radacct_eduroam SET FramedIPAddress = '10.36.10.174', AcctSessionTime = '586', AcctInputOctets = '0' << 32 | '59700', AcctOutputOctets = '0' << 32 | '83072' WHERE AcctSessionId = '53424d00/00:0a:5b:3a:b5:90/224195' AND UserName = '' AND NASIPAddress= '10.199.21.8'UPDATE radacct_eduroam SET FramedIPAddress = '10.36.10.174', AcctSessionTime = '586', AcctInputOctets = '0' << 32 | '59700', AcctOutputOctets = '0' << 32 | '83072' WHERE AcctSessionId = '53424d00/00:0a:5b:3a:b5:90/224195' AND UserName = '' AND NASIPAddress= '10.199.21.8'; ; That's right - an UPDATE statement is written twice in one line, and not separated by semicolon. The semicolon sits in its own newline. Unsurprisingly, when played back with radsqlrelay, the statement fails with the "trailing garbage" that is the second UPDATE. The UPDATE statement itself as per config is NOT duplicated of course. I also see plenty of other UPDATEs coming from the same line of config which are not-replicated as they should be. So some race condition maybe? Greetings, Stefan -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66