So I'm developing a patch to fix this issue, but I'm not exactly sure what the configuration should look like. I see multiple options, but the one I like the best is the following:
Add two new HBA configuration options: radiusfallbackservers and radiusfallbackports; both lists parsed with SplitIdentifierString (Ã la listen_addresses).
Why add new GUCs for that? Can't we just redefine radiusserver as a list of servers to try in sequence, and similarly split radiusport into a list?
Or maybe better, rename it radius_servers. But what you have here seems weird, and it certainly doesn't follow the precedent of what we did when we replaced listen_address with listen_addresses.
If we were adding RADIUS support today, this would be the best option. But seeing that we still only support one server today, this seems like a backwards incompatibility which practically 100% of users won't benefit from. But I don't care much either way. If we think breaking compatibility here is acceptable, I'd say we go for radius_servers and radius_ports.
We could change it to radius_servers and radius_ports, and deprecate but keep accepting the old parameters for a release or two. To make it easy, we make sure that both parameter names accepts the same format parameter, so it's easy enough to just replace it once deprecated.
And we could consider throwing a WARNING or at least a LOG when the old name is used, indicating that it's deprecated.
