Re: BUG #2246: Bad malloc interactions: ecpg, openssl
От | Andrew Klosterman |
---|---|
Тема | Re: BUG #2246: Bad malloc interactions: ecpg, openssl |
Дата | |
Msg-id | Pine.LNX.4.53L-ECE.CMU.EDU.0602141520410.29413@blossom.pdl.cmu.edu обсуждение исходный текст |
Ответ на | Re: BUG #2246: Bad malloc interactions: ecpg, openssl (Stephen Frost <sfrost@snowman.net>) |
Список | pgsql-bugs |
On Tue, 14 Feb 2006, Stephen Frost wrote: <snip> > It's kind of a chicken-and-egg here because the backend decides what > authentication mechanism to ask for based off the username (at least in > part) through pg_hba.conf, so you can't find out the authentication > method until you know the username so all methods to find the username > have to be exhausted. You could avoid this by explicitly passing > 'user=' into the connection parameters though... Would be interesting > to know what happens then... When asking about "explicitly passing 'user=' in to the connection parameters" do you mean that the EXEC SQL CONNECT line that ecpg parses should specify a username? My code is using the following statement when making a remote connection that uses SSL. EXEC SQL CONNECT TO :l_target AS :l_connection USER :l_user IDENTIFIED BY :l_passwd; The target machine (hosting the database) has "ssl=on" in postgresql.conf and in its pg_hba.conf (snippet below) a line for the client machine from which I am making the connection that specifies an SSL connection should be made. # TYPE DATABASE USER CIDR-ADDRESS METHOD hostssl andrew5 andrew5 172.19.130.4/32 pam passwd --Andrew J. Klosterman andrew5@ece.cmu.edu
В списке pgsql-bugs по дате отправления: