I wrote:
> Christoph Berg <c...@df7cb.de> writes:
>> libpq wants the user home directory to find .pgpass and
>> .pg_service.conf files, but apparently the behavior to require the
>> existence of the passwd file (or nss equivalent) is new in 9.4.
> There is demonstrably no direct reference to /etc/passwd in the PG code.
> It's possible that we've added some new expectation that $HOME can be
> identified, but a quick look through the code shows no such checks that
> don't look like they've been there for some time.
Hmm ... actually, I'll bet it's not $HOME that's at issue, but the name
of the user. Commit a4c8f14364c27508233f8a31ac4b10a4c90235a9 turned
failure of pg_fe_getauthname() into a hard connection failure, whereas
previously it was harmless as long as the caller provided a username.
I wonder if we shouldn't just revert that commit in toto. Yeah,
identifying an out-of-memory error might be useful, but this cure
seems a lot worse than the disease. What's more, this coding reports
*any* pg_fe_getauthname failure as "out of memory", which is much worse
than useless.
Alternatively, maybe don't try to resolve username this way until
we've found that the caller isn't providing any username.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
