[BUGS] BUG #1389: 2 x 3.1 Gz Intel Cpu, 4Gb RAM, 2Gb Swap, Linux, Kernel 2.4.21-20.ELsmp #1 SMP
The following bug has been logged online: Bug reference: 1389 Logged by: Gustav Lindenberg Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0.0rc2 Operating system: Red Hat Enterprise Linux ES release 3 (Taroon Update 3) Description:2 x 3.1 Gz Intel Cpu, 4Gb RAM, 2Gb Swap, Linux, Kernel 2.4.21-20.ELsmp #1 SMP Details: I get the following error when trying to copy(select) to a text file using psql: "out of memory for query result" The error comes up after about 45 minutes when free swap hist 0. This is my steps: $ psql claim \o claim_summary_old.unl claim=# \a Output format is unaligned. claim=# select * from claim_summary where cs_ch_serial < 21778534; out of memory for query result Table claim_summary has +-2900 rows. Need to unload +- 2000 rows to text file. When I change the select to a delete statement it works without error. Other system info: $ ipcs -m 0x0052e2c1 131076 postgres 600 591732736 3 $ rpm -qa |grep -i gcc libgcc-ssa-3.5ssa-0.20030801.48 gcc-java-ssa-3.5ssa-0.20030801.48 gcc-g77-ssa-3.5ssa-0.20030801.48 gcc-3.2.3-42 gcc-objc-ssa-3.5ssa-0.20030801.48 gcc-g77-3.2.3-42 gcc-java-3.2.3-42 gcc-c++-ssa-3.5ssa-0.20030801.48 gcc-ssa-3.5ssa-0.20030801.48 gcc-objc-3.2.3-42 libgcc-3.2.3-42 gcc-gnat-3.2.3-42 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[BUGS] rc4 and rc3, some deleted, but still needed text in the documentation, please put it back again
If PostgreSQL is intalled with native language support with the windows installer and if German is used as locale, local characters like Umlaute are displayed wrong in the windows command window. In PG-Admin's Helpfile, which is from beta5, but no longer in the documentation of version rc3 and rc4, the following advice can be found: psql is compiled as a âconsole applicationâ. As the Windows console windows use a different encoding than the rest of the system, you must take special care when using 8-bit characters at the psql prompt. When psql detects a problematic console code page, it will warn you at startup. To change the console code page, two things are neccessary: * Set the code page by entering cmd.exe /c chcp 1252. (1252 is a code page that is appropriate for German; replace it with your value.) If you are using Cygwin, you can put this command in /etc/profile. * Set the console font to âLucida Consoleâ, because the raster font does not work with the ANSI code page. This effectivly cures the problem. Thus, the above text should be placed back into the documentation. The file to be changed back is: PostgreSQL/8.0.0-rc4/doc/html/install-win32.html Perhaps on Windows, PostgreSQL should itself send "cmd.exe /c chcp 1252" to the console if needed. Perhaps it is trying to do this but it does not work in my case. This would explain why the documentation was changed. Regards Christoph Becker ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[BUGS] rc4, PostgreSQL-installer on WinXP: problems with plpython
1. Python as PL was greyed out an could not be installed again via the installer - contrary to rc3, where PL/Python's installation was offered and did work. 2. When trying to install plpythonu with creatlang, this was not possible because of something like "error in python.dll: python23.dll not fount" On my system python23 was replaced with python24 some days ago. Only when I copied python23.dll to c:/windows/system32, createlang did create plpythonu. It was not sufficient to copy python23.dll to C:\Programme\PostgreSQL\8.0.0-rc4\lib If PostgreSQL needs python23.dll, the installer should have it, should copy it into C:\Programme\PostgreSQL\8.0.0-rc4\lib and createlang.exe should first search it there. Other programms as winide, and natlink, which too still use python23.dll do indeed have there own copy with them and have it in there own privat lib-directory. Regards Christoph Becker ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[BUGS] rc4, PostgreSQL-installer on WinXP: anybody can read, write and delete in data-dir
The default file and directory-rights set by postgesql for the data directory are such, that anybody has the right to read, write and delete files. The installer as well as initdb should set reasonable rights or the user should at least be warned that he should adjust the file and directory rights. Regards Christoph Becker ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[BUGS] rc4, PostgreSQL-installer on WinXP: ignores selected install-directory
I wanted to install rc4 on Windows XP in g:\pgsql and selected this in the Installprocess. PGDATA was already set to this directory. However, PostgeSQL as well as the data-directory were installed at C:\Programme\PostgreSQL\8.0.0-rc4 resp. C:\Programme\PostgreSQL\8.0.0-rc4\data Initdb and pg_ctl start as user postgres did find PGDATA (which I set as universal system variable) Regards Christoph Becker ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[BUGS] rc4, restore of a db with psql freezes without warning if plpythonu is needed, but is not installed
I tryed to load a database dumped from version 7.4.3 which has a function written in plpython. The process seems to freeze at a "Create function" when I used psql and the text-version of the dump. After installing plpythonu it works. psql should print an error-message indicting that plpython (or what pl ever is needed) should be installed with creatlang before loading this database. Regards Christoph Becker ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] RULES doesn't work as expected
Removed cc to pgsql-patches since that's not the list for this.
John Hansen wrote:
It seems rules don't work as expected.
I could be wrong,... In which case, what am I doing wrong?
A rule is like a macro, rewriting the query plan. You're trying to use
it as though it is a trigger. The side-effects of rules can be quite
subtle and catches most of us out at least once.
Clearly, the first insert below should not update the table as well.
CREATE TABLE test (a text, b int4[]);
CREATE RULE test_rule AS
ON INSERT TO test
WHERE exists(SELECT 1 FROM test WHERE a = NEW.a)
DO INSTEAD
UPDATE test SET b = b + NEW.b WHERE a = NEW.a;
db1=# INSERT INTO test (a,b) VALUES (1,'{1}'::int4[]);
The NEW.a doesn't refer to a variable as such, it refers to the
updated/inserted value of an actual row in "test". Does that clarify?
In your particular usage you'd want to consider concurrency and locking
issues too.
Repost your question on the general/sql lists if you'd like some
discussion. It's probably worth checking the list archives too - plenty
in there about rule/trigger differences.
--
Richard Huxton
Archonet Ltd
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [BUGS] rc4, PostgreSQL-installer on WinXP: anybody can read, write and delete in data-dir
This permission is inherited from your Program Files folder, if you install in the default location. If you install with the data on a separate partition (which would be recommended for any larger installation), it's inherited from whatever the parent permissions are there. Might be worthwhile to add a notice to the installation instructions and/or FAQ about this. Will look into that. //Magnus > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Christoph Becker > Sent: Wednesday, January 12, 2005 11:14 AM > To: pgsql-bugs@postgresql.org > Subject: [BUGS] rc4, PostgreSQL-installer on WinXP: anybody > can read, write and delete in data-dir > > The default file and directory-rights set by postgesql for > the data directory are such, that anybody has the right to > read, write and delete files. > The installer as well as initdb should set reasonable rights > or the user should at least be warned that he should adjust > the file and directory rights. > > Regards > Christoph Becker > > > ---(end of > broadcast)--- > TIP 7: don't forget to increase your free space map settings > ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] rc4 and rc3, some deleted, but still needed text in the documentation, please put it back again
> If PostgreSQL is intalled with native language support with > the windows installer and if German is used as locale, local > characters like Umlaute are displayed wrong in the windows > command window. In PG-Admin's Helpfile, which is from beta5, > but no longer in the documentation of version rc3 and rc4, > the following advice can be found: This information is still in the documentation, it has moved to a different location. It's in the docmentation for the psql tool now. (It's under Client Application) > Perhaps on Windows, PostgreSQL should itself send "cmd.exe /c > chcp 1252" > to the console if needed. 1252 is not valid for all installations. Only for Latin-1 installations. That said, it should be possible to determine this from the system locale on installation time and put that in the shortcut. Please register a feature request on the pgFoundry page for this so it's not forgotten. It won't be there in time for 8.0, but it shouldn't be too much work to add it in a followon release. //Magnus ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] rc4, PostgreSQL-installer on WinXP: problems with plpython
> 1. Python as PL was greyed out an could not be installed > again via the installer - contrary to rc3, where PL/Python's > installation was offered and did work. This means that you don't have python23.dll on your system. > 2. When trying to install plpythonu with creatlang, this was > not possible because of something like "error in python.dll: > python23.dll not fount" > On my system python23 was replaced with python24 some days ago. Python24 is not currently supported by the binary installer (see the installation instructions). > Only when I copied python23.dll to c:/windows/system32, > createlang did create plpythonu. > It was not sufficient to copy python23.dll to > C:\Programme\PostgreSQL\8.0.0-rc4\lib Correct. It might work if you put it in 8.0.0-rc4\bin though. Or add the directory where it's already in to your PATH. > If PostgreSQL needs python23.dll, the installer should > have it, should copy it into > C:\Programme\PostgreSQL\8.0.0-rc4\lib and createlang.exe > should first search it there. I *think* we require a full python installation, not just the DLL file. I'm not 100% sure on that. It currently supports Python23, which is also in the installation instructions. If someone can confirm that we need only the DLL, we can definitly include it in our distribution. So - can someone who knows enoughh aboyt plpython speak up on that one? //Magnus ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] rc4, PostgreSQL-installer on WinXP: ignores selected install-directory
> I wanted to install rc4 on Windows XP in g:\pgsql and > selected this in the Installprocess. > PGDATA was already set to this directory. > However, PostgeSQL as well as the data-directory were installed at > C:\Programme\PostgreSQL\8.0.0-rc4 > resp. > C:\Programme\PostgreSQL\8.0.0-rc4\data > Initdb and pg_ctl start as user postgres did find PGDATA > (which I set as universal system variable) The installer will override any environment variables, as it executes with its own environment in Windows Installer. To change a directory, use the installer features for it. See the FAQ question 3.6. //Magnus ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] RULES doesn't work as expected
Right, except:
create table test (a text, b int);
create or replace rule test_rule as on insert to test where exists(select 1
from test where a = NEW.a) do instead select * from test;
insert into test (a,b) VALUES ('first',2);
a | b
---+---
first | 2
(1 row)
select * from test;
a | b
---+---
first | 2
(1 row)
Now, the select on the first insert should NOT have happened. Since this is
a do instead rule.
The insert should of course happen, since it's not present in the table.
Or am I missing the point completely?
... John
> -Original Message-
> From: Richard Huxton [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, January 12, 2005 10:22 PM
> To: John Hansen
> Cc: pgsql-bugs@postgresql.org
> Subject: Re: [BUGS] RULES doesn't work as expected
>
> Removed cc to pgsql-patches since that's not the list for this.
>
> John Hansen wrote:
> > It seems rules don't work as expected.
> > I could be wrong,... In which case, what am I doing wrong?
>
> A rule is like a macro, rewriting the query plan. You're
> trying to use it as though it is a trigger. The side-effects
> of rules can be quite subtle and catches most of us out at least once.
>
> > Clearly, the first insert below should not update the table as well.
>
> > CREATE TABLE test (a text, b int4[]);
> >
> > CREATE RULE test_rule AS
> > ON INSERT TO test
> > WHERE exists(SELECT 1 FROM test WHERE a = NEW.a)
> > DO INSTEAD
> > UPDATE test SET b = b + NEW.b WHERE a = NEW.a;
> >
> >
> > db1=# INSERT INTO test (a,b) VALUES (1,'{1}'::int4[]);
>
> The NEW.a doesn't refer to a variable as such, it refers to
> the updated/inserted value of an actual row in "test". Does
> that clarify?
>
> In your particular usage you'd want to consider concurrency
> and locking issues too.
>
> Repost your question on the general/sql lists if you'd like
> some discussion. It's probably worth checking the list
> archives too - plenty in there about rule/trigger differences.
> --
>Richard Huxton
>Archonet Ltd
>
>
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
[BUGS] 8rc5 on OpenBSD
Hi, I try a "make check" without success. The compilation is done correctly. But "make check" throws: == creating temporary installation== == initializing database system == == starting postmaster== running on port 65432 with pid 17114 == creating database "regression" == createdb: could not connect to database template1: could not connect to server: No such file or directory Is the server running locally and accepting connections on Unix domain socket "/tmp/.s.PGSQL.65432"? pg_regress: createdb failed gmake[2]: *** [check] Error 2 rm regress.o gmake[2]: Leaving directory `/admin/install/pg/postgresql-8.0.0rc5/src/test/regress' gmake[1]: *** [check] Error 2 gmake[1]: Leaving directory `/admin/install/pg/postgresql-8.0.0rc5/src/test' gmake: *** [check] Error 2 *** Error code 2 Stop in /admin/install/pg/postgresql-8.0.0rc5 (line 19 of Makefile). admin has logged on ttyp1 from imac. # cat src/test/regress/log/postmaster.log WARNING: could not create Unix-domain socket LOG: database system was shut down at 2005-01-12 14:25:10 CET LOG: checkpoint record is at 0/A3E614 LOG: redo record is at 0/A3E614; undo record is at 0/0; shutdown TRUE LOG: next transaction ID: 544; next OID: 17230 LOG: database system is ready LOG: received fast shutdown request LOG: shutting down LOG: database system is shut down I recompile with the option for configure from the 7.4 ports. Nothing better. Any help welcomed. Cordialement, Jean-Gérard Pailloncy ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] RULES doesn't work as expected
John Hansen wrote:
Right, except:
create table test (a text, b int); create or replace rule test_rule
as on insert to test where exists(select 1 from test where a = NEW.a)
do instead select * from test;
insert into test (a,b) VALUES ('first',2); a | b ---+--- first
| 2 (1 row)
select * from test; a | b ---+--- first | 2 (1 row)
Now, the select on the first insert should NOT have happened.
Since this is a do instead rule. The insert should of course happen,
since it's not present in the table.
Or am I missing the point completely?
You are, but it's not your fault. You're still thinking of it as a
sequence of instructions, try thinking of it as a single expression that
gets evaluated.
To quote from the (v8.0) docs (ch 32 - The Rule System), for your case:
"Qualification given and INSTEAD
the query tree from the rule action with the rule qualification and
the original query tree's qualification; and the original query tree
with the negated rule qualification added"
So, in your case you get two branches:
1. INSERT ... WHERE NOT EXISTS (...)
2. SELECT * FROM TEST WHERE EXISTS (...)
Is this making sense?
--
Richard Huxton
Archonet Ltd
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [BUGS] 8rc5 on OpenBSD
Pailloncy Jean-Gerard <[EMAIL PROTECTED]> writes: > # cat src/test/regress/log/postmaster.log >> WARNING: could not create Unix-domain socket Hmm. That's pretty odd --- the warning indicates that StreamServerPort() failed to open a local socket, but all of the expected failure paths will log an additional message saying why it couldn't open the socket. The only code path I see offhand in which no message would be logged is if the ListenSocket[] array is already full. Is it possible that you have 10 or more IP addresses that "localhost" would bind to? regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [BUGS] 8rc5 on OpenBSD
Pailloncy Jean-Gerard <[EMAIL PROTECTED]> writes: The only code path I see offhand in which no message would be logged is if the ListenSocket[] array is already full. Is it possible that you have 10 or more IP addresses that "localhost" would bind to? >> >>> 2 IPs + 3 alias on 2 interfaces >>> 1 IPs + 27 alias on 1 loopback interface >> >> Wow. Try increasing the MAXLISTEN constant in >> src/backend/postmaster/postmaster.c. > Bump it to 100. Good. > I sugess a better error message. Done. It never occurred to anyone that that limit would actually be reached, I suppose. >> === >> 8 of 96 tests failed. >> === Seems like you've still got some issues though. What do the detailed diffs look like? regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] 8rc5 on OpenBSD
Pailloncy Jean-Gerard <[EMAIL PROTECTED]> writes: > === > 8 of 96 tests failed. > === The failures all seem to be due to individual tests not getting run: > ! psql: could not fork new process for connection: Resource temporarily > unavailable > ! psql: could not fork new process for connection: Resource temporarily > unavailable > ! psql: could not fork new process for connection: Resource temporarily > unavailable > ! psql: could not fork new process for connection: Resource temporarily > unavailable > ! psql: could not send startup packet: Broken pipe > ! psql: could not send startup packet: Broken pipe (the other two failures are because tables these tests should have created didn't get created) The fork failures are easy enough to explain: you have the per-user process limit set too low. I suspect the "broken pipe" failures have the same root cause, but they do seem a bit odd. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
[BUGS] rc5: initdb freeze with "selecting default max_connections ..."
System is Windows XP, the postgres-installer (postgresql-8.0.0-rc5.zip resp. .msi) was used to install envirement variable PGDATA is set to g:\pgsql Never before (7.x versions, older version 8 beta/rc) I have got the following response/problem with an initdb: C:\Programme\PostgreSQL\8.0.0-rc5\bin>initdb The files belonging to this database system will be owned by user "postgres". This user must also own the server process. The database cluster will be initialized with locale German_Germany.1252. creating directory G:/pgsql/data ... ok creating directory G:/pgsql/data/global ... ok creating directory G:/pgsql/data/pg_xlog ... ok creating directory G:/pgsql/data/pg_xlog/archive_status ... ok creating directory G:/pgsql/data/pg_clog ... ok creating directory G:/pgsql/data/pg_subtrans ... ok creating directory G:/pgsql/data/base ... ok creating directory G:/pgsql/data/base/1 ... ok creating directory G:/pgsql/data/pg_tblspc ... ok selecting default max_connections ... At this point initdb did freeze time and again. However, before initdb seemed to have worked, when it was used by the PostgreSQL-Windows-Installer. Regards Christoph Becker ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [BUGS] rc4, PostgreSQL-installer on WinXP: ignores selected install-directory
The installer will override any environment variables, as it executes
with its own environment in Windows Installer. To change a directory,
use the installer features for it. See the FAQ question 3.6.
I did that, and here is FAQ 3.6:
I changed the directory but PostgreSQL was still installed in the
default directory
Make sure you changed the directory of the root feature. The PostgreSQL
installer permits changing the directory of each individual feature. If
you change the root feature ("PostgreSQL"), any subfeatures (such as
"Database Server") will automatically inherit this value as default, but
if you only change a subfeature the rest of the installation will remain
in the default location.
I can find only one dialog to change the directory, that is where the
following ist offered on my system:
"C:\Programme\PostgreSQL\8.0.0-rc5\" [browse]
But FAQ 3.6 suggests that there are more dialogs to change
subdirectories too.
I tried without success:
g:\pgsql\PostgreSQL\8.0.0-rc5\ and g:\pgsql\"
which did not work.
Finally, after reading again FAQ 3.6 I tried
'g:\pgsql\8.0.0-rc5', which worked fine. So the version-part, which here
is '8.0.0-rc5', must be the last part path.
By this there will be an new directory for every release, which seems
reasonable.
I think there should be given an example like in FAQ 3.6 or even better
in the installation dialog.
Something like:
If 'C:\Programme\PostgreSQL\8.0.0-rc5\' is given here as default
and you would like to install in d:\pgsql, then please
change to 'd:\pgsql\8.0.0-rc5\'
Regards
Christoph Becker
Magnus Hagander schrieb:
I wanted to install rc4 on Windows XP in g:\pgsql and
selected this in the Installprocess.
PGDATA was already set to this directory.
However, PostgeSQL as well as the data-directory were installed at
C:\Programme\PostgreSQL\8.0.0-rc4
resp.
C:\Programme\PostgreSQL\8.0.0-rc4\data
Initdb and pg_ctl start as user postgres did find PGDATA
(which I set as universal system variable)
The installer will override any environment variables, as it executes
with its own environment in Windows Installer. To change a directory,
use the installer features for it. See the FAQ question 3.6.
//Magnus
---(end of broadcast)---
TIP 8: explain analyze is your friend
[BUGS] 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 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [BUGS] rc4 and rc3, some deleted, but still needed text in the
Magnus Hagander wrote: This information is still in the documentation, it has moved to a different location. It's in the docmentation for the psql tool now. (It's under Client Application) Yes it is, but the message in the source code has not been changed, which is very misleading, as you can see here: g:\home\cb>psql -U postgres template1 Password: Welcome to psql 8.0.0rc5, the PostgreSQL interactive terminal. .. Warning: Console codepage (850) differs from windows codepage (1252) 8-bit characters will not work correctly. See PostgreSQL documentation "Installation on Windows" for details. Regards Christoph Becker Magnus Hagander schrieb: If PostgreSQL is intalled with native language support with the windows installer and if German is used as locale, local characters like Umlaute are displayed wrong in the windows command window. In PG-Admin's Helpfile, which is from beta5, but no longer in the documentation of version rc3 and rc4, the following advice can be found: This information is still in the documentation, it has moved to a different location. It's in the docmentation for the psql tool now. (It's under Client Application) Perhaps on Windows, PostgreSQL should itself send "cmd.exe /c chcp 1252" to the console if needed. 1252 is not valid for all installations. Only for Latin-1 installations. That said, it should be possible to determine this from the system locale on installation time and put that in the shortcut. Please register a feature request on the pgFoundry page for this so it's not forgotten. It won't be there in time for 8.0, but it shouldn't be too much work to add it in a followon release. //Magnus ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] psql: no chance to enter password in certain situations
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. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [BUGS] psql: no chance to enter password in certain situations
Christoph Becker <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
