That is very odd.
I note you are running custom SQL queries against a union of a password
table and a stored procedure - it is possible something occurs inside
the stored proc that causes a backend to lock up or start behaving
abnormally.
What happens if you execute:
SELECT -1 AS id, username,'User-Password' AS attribute, password AS
value, '==' AS op ??FROM raduser WHERE username = 'jack'
UNION
SELECT * FROM radius_authorise_check('jack','skyrove_bree') ORDER BY id;
...repeatedly inside "psql" (with a connection using the same parameters
at the FreeRadius driver)?
Note that you are incorrect about the connections being "dropped", and
that you should not expect round-robin behaviour. The server will open a
certain number of sockets. When a request comes in, the server grabs an
unused socket from the list, uses it, and returns it. Which socket you
get cannot be easily predicted.
rlm_sql (auth): Reserving sql socket id: 0
rlm_sql (auth): Released sql socket id: 0
Sending Access-Accept of id 38 to 165.146.6.102 port 2322
rlm_sql (auth): Reserving sql socket id: 0
rlm_sql (auth): Released sql socket id: 0
Sending Access-Reject of id 39 to 165.146.6.102 port 2323
That is, both request went to the same socket (and thus postmaster backend).
I would suggest bumping the logging on postgres and seeing if you can
determine why a query against the same backend, on the same connection,
fails on subsequent calls.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
