* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost <sfr...@snowman.net> writes: > > Having @include and directory.d-style capabilities for pg_hba.conf *and* > > pg_ident.conf would make managing larger environments much better. > > I'm a little suspicious of this, mainly because pg_hba searching is > necessarily linear (and none too cheap per-entry). I think anyone > who tries to use a set of entries large enough to really need multiple > files is going to have pain.
It would depend on the connection rate- some of these environments have low connection rate but quite a few users (eg: corporate database server). As expressed up-thread, and in my own experience, people are already doing this by building up the files themselves, so I don't agree that performance would be so bad that this isn't worth it. Not everyone is using PG to back their website. Improving performance would always be good too, or perhaps providing another mechanism which performs better when there are more entries. > We already have various methods for making one pg_hba entry do the > work of many; for instance, IP-subnet entries, wildcards, and role > references. And you can use database CONNECT privilege grants as > another substitute for fine-grained pg_hba entries. Yes, but those entries all have to agree on the exact authentication method, including any mappings or other options which are passed through pg_hba.conf. Also, CONNECT is only true/false, it doesn't have any ability to consider source-IP, SSL, etc. > I'd be interested to see a real use-case where those things aren't > an adequate substitute for a pg_hba rule set that's too large to > fit conveniently in one file. Maybe we could identify another > pg_hba abstraction technique we need to support. Being able to 'fit' inside of one file is wholly in the eye of the beholder and isn't terribly relevant either. Larger installations will be using puppet, chef, or one of the other configuration management systems and will want to use even small/independent files rather than having to write code which fools around with the one file approach. The files I have in /etc/cron.d/ aren't particularly large, but it's really nice to be able to independently manage and deploy them without templating them. Also, all of the above ignores the pg_ident side of the house, which is even worse as you need an entry for every user, period, if you're using client-side SSL certificates or Kerberos/GSSAPI-based authentication with full princ names. > 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? Thanks, Stephen
signature.asc
Description: Digital signature