2013/12/5 Euler Taveira <[email protected]> > On 05-12-2013 10:03, Matheus de Oliveira wrote: > > Quando se usa usuários logados na aplicação para logar no banco também, > > fica praticamente impossível utilizar pool de conexões. Simples assim. > Uma > > conexão é sempre associada ao par usuário+banco, e, se você quer trocar > de > > usuário (mesmo que esteja no mesmo banco), terás de fechar a conexão e > > abrir uma nova. > > > > Eu disse que poderia não ter, porque se pensarmos só no PostgreSQL em si, > > não teria diferença, já que ele não tem pool de conexões nativamente > mesmo. > > Mas impossibilitaria uso deste externamente (como com o pgBouncer). E, > todo > > DBA sabe, que para aplicação com muitos usuários o pool de conexão se > torna > > essencial. > > > Pelo menos com pgBouncer, não impossibilitaria. Se você especificar o > 'user' na string de conexão, o pgBouncer utilizará o usuário informado > para autenticação somente para se autenticar nele. A conexão > estabelecida com o Postgres será feita pelo 'user' informado na string > de conexão. > > No pgbouncer.ini: > > forcedb = host=127.0.0.1 port=300 user=baz password=foo > > Fazendo uma conexão no pgBouncer: > > $ psql -h 10.0.0.2 -U teste -p 6432 forcedb > > Neste caso, 'teste' será usado para se autenticar no pgBouncer mas o > usuário que estabelece a conexão com o Postgres é o 'baz'. > > Ok. Mas veja que nesse caso não teria a vantagem de GRANTs e REVOKEs específicos para esse usuário.
Ou seja, o pgBouncer seria usado como uma camada de autenticação (além do pool, claro). Não estou dizendo que isso é ruim, me parece até uma ideia bacana, só que há limitações. Atenciosamente, -- Matheus de Oliveira Analista de Banco de Dados Dextra Sistemas - MPS.Br nível F! www.dextra.com.br/postgres
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
