From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Jorge Gustavo Rocha <jgr(at)geomaster(dot)pt>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #15827: Unable to connect on Windows using pg_services.conf using Python psycopg2 |
Date: | 2019-06-20 03:12:18 |
Message-ID: | 20190620031218.GC2660@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Wed, Jun 19, 2019 at 04:44:58PM -0400, Tom Lane wrote:
> Ah-hah! That explains much. So a non-invasive fix would be to force
> parseServiceFile to open the file in text mode; I think this would
> work for that:
>
> - f = fopen(serviceFile, "r");
> + f = fopen(serviceFile, "rt");
>
> I don't think that that's really a good solution, because it does little
> to prevent the same problem from reappearing elsewhere. But if we wanted
> the smallest possible fix that might do.
Actually I think that something like 40cfe86 may be a solution to look
at (combined with 0ba06e0 except for the portions enforcing the text
flags like in initdb). This stuff found its way only in 12~, but
having us switching to the concurrent-safe version for fopen() that we
bundle in port/ has the advantage to take care of this issue, because
on HEAD, if 'b' or 't' are not defined, then we enforce to text mode.
Still back-patching that is sensitive and we have known that hard last
year..
The discussion here is on 10, and the password file has does not
enforce the flag either because it filters '\r' by itself. So another
solution may be to do the same thing as what's done in
passwordFromFile()?
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Sergei Kornilov | 2019-06-20 06:56:51 | Re: BUG #15861: jsonb exists query retuning inconsistent results |
Previous Message | Michael Paquier | 2019-06-20 02:49:41 | Re: BUG #15789: libpq compilation with OpenSSL 1.1.1b fails on Windows with Visual Studio 2017 |