Re: BUG #19388: Failing to connect to postgres with EACCES error

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>
Cc: gc(dot)nugent66(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #19388: Failing to connect to postgres with EACCES error
Date: 2026-01-23 20:31:48
Message-ID: 3137619.1769200308@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> writes:
> On Fri, Jan 23, 2026 at 7:35 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> If anything, I'd lean towards removing the special exception for
>> ENOTDIR ... I wonder why that's there.

> I think removing that would take some adjustments to
> pqGetHomeDirectory(), so that it actually checks for the existence of
> that directory before returning true. `have_homedir` is kind of a
> misleading name in this context.

I dug into our git history and traced the appearance of ENOTDIR to

commit 5b40677986984d450a2a16e515fe44d90dfeef02
Author: Magnus Hagander <magnus(at)hagander(dot)net>
Date: Sat Dec 3 15:02:53 2011 +0100

Treat ENOTDIR as ENOENT when looking for client certificate file

This makes it possible to use a libpq app with home directory set
to /dev/null, for example - treating it the same as if the file
doesn't exist (which it doesn't).

Per bug #6302, reported by Diego Elio Petteno

We could imagine pushing the stat() test into pqGetHomeDirectory,
which might be a more sensible factorization, but I don't think
it'd move the behavior much.

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Previous Message Jacob Champion 2026-01-23 20:01:18 Re: BUG #19388: Failing to connect to postgres with EACCES error