Thread: BUG #10347: Can't write password to psql or pg_dump
The following bug has been logged on the website: Bug reference: 10347 Logged by: Derek Ealy Email address: derek_ealy@rapid7.com PostgreSQL version: 9.3.4 Operating system: Windows Description: When exec'ing a command to pg_dump or psql from Java there is no "normal" way to send the password to the psql process. On Linux systems it works as expected because I write the password to the input stream of the process running psql. On Windows systems the psql or pg_dump process always hangs after sending the password to stdin of the process. I've gotten around this problem by setting an environment variable before exec'ing the process. I set OSTYPES=msys. This forces psql to use stdin when reading the password. It's not a documented feature, but I found it in the source code. I think there should be a documented way of telling psql and pg_dump to pull the password from stdin.
On Fri, May 16, 2014 at 08:34:09PM +0000, derek_ealy@rapid7.com wrote: > When exec'ing a command to pg_dump or psql from Java there is no "normal" > way to send the password to the psql process. >=20 > On Linux systems it works as expected because I write the password to the > input stream of the process running psql. Normal way of providing password is either to use PGPASSWORD environment variable, as shown here: http://www.postgresql.org/docs/current/interactive/libpq-envars.html or pgpass file, as shown here: http://www.postgresql.org/docs/current/interactive/libpq-pgpass.html depesz
Hi, On 2014-05-16 20:34:09 +0000, derek_ealy@rapid7.com wrote: > On Windows systems the psql or pg_dump process always hangs after sending > the password to stdin of the process. > > I've gotten around this problem by setting an environment variable before > exec'ing the process. I set OSTYPES=msys. This forces psql to use stdin when > reading the password. I think the important point - and why I asked for a bugreport after talking about it on irc - is that sprompt.c on windows uses CONIN$/CONOUT$ for io. Ignoring stdin/stdout except when the OSTYPE is set to msys. Given that CONIN$/OUT seem to refer to the shell that started a processtree from a shell that doesn't seem to be optimal. That said, I am not a big fan of relying on sending the passwort to stdin... Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Andres Freund <andres@2ndquadrant.com> writes:
> I think the important point - and why I asked for a bugreport after
> talking about it on irc - is that sprompt.c on windows uses
> CONIN$/CONOUT$ for io.
I have some recollection we changed to that after determining that the
alternatives were worse. [ Checks git logs ] You should investigate the
discussion leading up to commit 1068771abfeec148a9c1ce4782785bddc1982070
before proposing any change here.
regards, tom lane
On Sun, May 18, 2014 at 12:23:24PM +0200, Andres Freund wrote: > On 2014-05-16 20:34:09 +0000, derek_ealy@rapid7.com wrote: > > On Windows systems the psql or pg_dump process always hangs after sending > > the password to stdin of the process. > > > > I've gotten around this problem by setting an environment variable before > > exec'ing the process. I set OSTYPES=msys. This forces psql to use stdin when > > reading the password. > > I think the important point - and why I asked for a bugreport after > talking about it on irc - is that sprompt.c on windows uses > CONIN$/CONOUT$ for io. Ignoring stdin/stdout except when the OSTYPE is > set to msys. Given that CONIN$/OUT seem to refer to the shell that > started a processtree from a shell that doesn't seem to be optimal. That code is trying to mimic the non-Windows behavior, which is to interact with /dev/tty when available. Unfortunately, CONIN$/CONOUT$ are ~always nominally available, but they may not route to anything visible to the user. The OSTYPE test is a crude attempt to anticipate that problem. IsWindowVisible(GetConsoleWindow()) looked more reliable, but it still didn't cover everything: http://www.postgresql.org/message-id/flat/20121010110555.GA21405@tornado.leadboat.com -- Noah Misch EnterpriseDB http://www.enterprisedb.com