| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | gc(dot)nugent66(at)gmail(dot)com |
| Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #19388: Failing to connect to postgres with EACCES error |
| Date: | 2026-01-23 15:35:45 |
| Message-ID: | 3106878.1769182545@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> Running on k8s pods, I have an issue where a process cannot connect to an
> Azure Postgres server due to a permission error.
> ...
> We use standard SSL without client certificates and the running process is
> setup without a homedir for security reasons.
I'm pretty skeptical that that is a good idea, but if you are stubborn
about it you could explicitly specify "sslcert=/no/such/file" and so
on in your connection parameters. Another way is to make the HOME
environment variable point at a directory that actually doesn't exist,
rather than one that has access restrictions.
> I noticed from the postgres source code that only ENOENT & ENOTDIR are
> allowable errors but EACCES is a fail condition.
> I understand the reasoning for checking for existence of certificates, but
> can the Permission Denied error also be treated as "Can't get client certs,
> continue to try to connect without"?
No, I don't think that would be an improvement in user experience
for most people. If your cert isn't working and libpq fails to
tell you why not, debugging that could be pretty unpleasant.
If anything, I'd lean towards removing the special exception for
ENOTDIR ... I wonder why that's there.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | surya poondla | 2026-01-23 18:22:38 | Re: BUG #19369: Not documented that io_uring on kernel versions between 5.1 and below 5.6 does not work |
| Previous Message | Tom Lane | 2026-01-23 15:16:49 | Re: BUG #19387: About Response time delay. |