| From: | Marko Tiikkaja <marko(at)joh(dot)to> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Supporting fallback RADIUS server(s) |
| Date: | 2015-08-20 00:36:33 |
| Message-ID: | 55D52111.1010206@joh.to |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2015-08-20 02:29, Tom Lane wrote:
> Marko Tiikkaja <marko(at)joh(dot)to> writes:
>> 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.
.m
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kouhei Kaigai | 2015-08-20 01:08:57 | Re: Our trial to TPC-DS but optimizer made unreasonable plan |
| Previous Message | Tom Lane | 2015-08-20 00:29:50 | Re: Supporting fallback RADIUS server(s) |