Tom Lane <tgl@sss.pgh.pa.us> writes:
> Stephen Frost <sfrost@snowman.net> writes:
>
>> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>>> In short: I suspect this approach may be fixing the wrong thing.
>
>> I'm curious what you're thinking would be the right thing to fix here?
>
> I was asking for use-cases so we could figure out what's the right thing ;-)
No doubt this environment I took over managing, of 90 clusters ranging
from tiny to ~3.5TB, some with hundreds of user accounts... could stand
some massive rejiggering in regards to users/rols and such to go towards
doing it "the right way".
That said, trying to roll up the hba files some with over 300 entries
and lots of cases of high duplication among clusters belonging to somne
subset, would be daunting and perhaps invasive.
I realize that gathering up those duplicates into a file common to
whatever group and then having that pulled in as an include is going to
result in some reordering of the rules since they are not in a totally
predictable order presently
And my Jr. DBAs are still handling requests daily to add more hba rules
quite often to more than a single machine but still along the same
groupings mentioned.
Even without retrofitting a "good" cleanup here, being able to include a
global section at top of all files and at least one group specific file
next then followed by legacy entries and/or items specific to a single
cluster, might save a lot of work.
Thus my idea of using a make file for this and then inspiring the
question about includes.
Great just getting the ball rolling and I respect whatever the concensus
opinion that emerges.
Thx
>
> The argument about wanting to assemble a pg_hba file from separately
> managed configuration pieces seems to have some merit, but the weak
> spot there is how do you define the search order? Or are you planning
> to just cross your fingers and hope it doesn't matter too much?
>
> regards, tom lane
>
--
Jerry Sievers
e: jerry.sievers@comcast.net
p: 312.241.7800
