Thread: psql: no chance to enter password in certain situations
OS ist Windows XP Prof, PgSQL version is rc5 via windowsinstaller When trying to restore a db, psql does not ask for the password but responds imediately with an erromessage as in the following example: F:\doka\bak>psql -U postgres template1 < pg_dump_all_2005-01-11.txt Password: psql: FATAL: password authentication failed for user "postgres" However, in the following situation the password can still be entered as expected : F:\doka\bak>psql -U postgres template1 Password: Welcome to psql 8.0.0rc5, the PostgreSQL interactive terminal. ...... Regards Christoph Becker
Christoph Becker wrote: > OS ist Windows XP Prof, PgSQL version is rc5 via windowsinstaller > When trying to restore a db, psql does not ask for the password but > responds imediately with an erromessage as in the following example: > > F:\doka\bak>psql -U postgres template1 < pg_dump_all_2005-01-11.txt > Password: > psql: FATAL: password authentication failed for user "postgres" > > However, in the following situation the password can still be entered as > expected : > > F:\doka\bak>psql -U postgres template1 > Password: > Welcome to psql 8.0.0rc5, the PostgreSQL interactive terminal. > ...... try -f instead of < like... psql -U postgres template1 -f pg_dump_all_2005-01-11.txt btw, personal 'trick', to avoid having to specify template1, I generally `createdb postgres` right after installing and doing the initdb. this way the postgres DBA account has his own personal playpen for testing SQL and stuff.
Christoph Becker <cgbecker@gmx.de> writes: > OS ist Windows XP Prof, PgSQL version is rc5 via windowsinstaller > When trying to restore a db, psql does not ask for the password but > responds imediately with an erromessage as in the following example: > F:\doka\bak>psql -U postgres template1 < pg_dump_all_2005-01-11.txt > Password: > psql: FATAL: password authentication failed for user "postgres" I'm not sure that it's possible to fix that. On Unix we read the password from /dev/tty not stdin, but on Windows that trick (probably) does not work, and we have to fall back to reading from stdin ... which you've stuffed with the input file. Better to use -f to source the input file. regards, tom lane