On 8/20/15 4:25 PM, Magnus Hagander wrote:
On Aug 20, 2015 4:16 PM, "Tom Lane" wrote:
Our expectations about forward compatibility for postgresql.conf entries
have always been pretty low; even more so for not-widely-used settings.
In any case, wouldn't what you describe simply put off the pain
On Aug 20, 2015 4:16 PM, "Tom Lane" wrote:
>
> Magnus Hagander writes:
> > On Thu, Aug 20, 2015 at 2:36 AM, Marko Tiikkaja wrote:
> >> On 2015-08-20 02:29, Tom Lane wrote:
> >>> Why add new GUCs for that? Can't we just redefine radiusserver as a
list
> >>> of servers to try in sequence, and sim
Magnus Hagander writes:
> On Thu, Aug 20, 2015 at 2:36 AM, Marko Tiikkaja wrote:
>> On 2015-08-20 02:29, Tom Lane wrote:
>>> 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?
> We could change
On 8/20/15 12:57 PM, Magnus Hagander wrote:
I mean that you could write radius_server=foo or radius_servers=foo as well
as radius_server=foo,bar and radius_servers=foo,bar. As long as you don't
specify both radius_server and radius_servers, either one of them should
accept either one server or mu
On Thu, Aug 20, 2015 at 12:55 PM, Marko Tiikkaja wrote:
> On 8/20/15 12:53 PM, Magnus Hagander wrote:
>
>> We could change it to radius_servers and radius_ports, and deprecate but
>> keep accepting the old parameters for a release or two.
>>
>
> That's one option..
>
> To make it easy, we
>> make
On 8/20/15 12:53 PM, Magnus Hagander wrote:
We could change it to radius_servers and radius_ports, and deprecate but
keep accepting the old parameters for a release or two.
That's one option..
To make it easy, we
make sure that both parameter names accepts the same format parameter, so
it's e
On Thu, Aug 20, 2015 at 2:36 AM, Marko Tiikkaja wrote:
> On 2015-08-20 02:29, Tom Lane wrote:
>
>> Marko Tiikkaja 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
On 2015-08-20 02:29, Tom Lane wrote:
Marko Tiikkaja 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: radiusfallb
Marko Tiikkaja 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
> radiusfallback
Hi,
We use RADIUS authentication at $WORK, and it has one major flaw (well,
two, but I already fixed the other one this week): it only supports
specifying a single server, which as we might know, is bad for high
availability. So I'm developing a patch to fix this issue, but I'm not
exactly s
10 matches
Mail list logo
