Re: [BUGS] BUG #4180: PANIC while PQExec on Client with differen locale from database
I got almost the same error: I dumped the database, which was in Latin9, with version 8.2.6 using UTF8 as encoding. Then loaded the database to version 8.3.1. Now the database was running with UTF8 while on the client still was iso-8859-15. As as result postgresql..exe did crash very often. Then I tried: $ pg_dump -U postgres -f pxdump-2008-05-19a-Latin9.txt -E='Latin9' px and got the following message: pg_dump: SQL command failed pg_dump: Error message from server: ERROR: character 0xc2a4 of encoding "UTF8" has no equivalent in "LATIN9" pg_dump: The command was: COPY public.p_behbl_log (lfdnr_log, lfdnr_behbl, patnr , datum, zahn_, zahn, behandlung, gebuehrenpos, ltyp, efs_bemerkung, anz, faktor , bemerkung, begruendung, material, punktzahl, punktsumme, punktwert, betrag, wa ehrung, fallnr, behandler, assistenz, createtime, sitzungskennz, unfallkennz, no tfallkennz, digest, digest_seq, abgerechnet, log_timestamp, log_user, log_reason ) TO stdout; in the Logfile I found: 2008-05-20 14:49:58 CEST ERROR: character 0xc2a4 of encoding "UTF8" has no equivalent in "LATIN9" 2008-05-20 14:49:58 CEST STATEMENT: COPY public.p_behbl_log (lfdnr_log, lfdnr_behbl, patnr, datum, zahn_, zahn, behandlung, gebuehrenpos, ltyp, efs_bemerkung, anz, faktor, bemerkung, begruendung, material, punktzahl, punktsumme, punktwert, betrag, waehrung, fallnr, behandler, assistenz, createtime, sitzungskennz, unfallkennz, notfallkennz, digest, digest_seq, abgerechnet, log_timestamp, log_user, log_reason) TO stdout; 2008-05-20 14:49:58 CEST LOG: could not receive data from client: Unknown winsock error 10061 2008-05-20 14:49:58 CEST LOG: unexpected EOF on client connection dumping just in utf8 did work. Obviously, the converison from Latin9 (and other encodings?) to UTF8 did produce some characters which can not be encoded back to the original encoding. Regards, Christoph Becker Tom Lane schrieb: [ please keep the mailing list cc'd on discussions ] "bishop.gis" <[EMAIL PROTECTED]> writes: This is result executing the same command with client_encoding = UTF8. ERROR: =CE=C5=D7=C5=D2=CE=C1=D1 = =D0=CF=D3=CC=C5=C4=CF=D7=C1=D4=C5=CC=D8=CE=CF=D3=D4=D8 =C2=C1=CA=D4 = =C9=CD=D1 =CB=CF=C4=C9=D2=CF=D7=CB=C9 "UTF8": 0xcdee (on English -- invalid UTF-8 byte sequence detected near byte 0xcdee) =F0=EF=E4=F3=EB=E1=FA=EB=E1: This error can also happen if the byte = sequence does not match the encoding expected by the server, which is controlled by "client_encoding". Hmm ... I don't read Russian, but I'm quite certain that what you sent isn't in UTF8. Perhaps it is in KOI8-R? This lends some weight to the theory I suggested that gettext() is failing to return UTF8 on Windows. That could be a red herring, since it's possible the encoding got changed when you copied the text into your mail message, but the theory seems to explain the observed facts so far. What locale settings are you using --- particularly lc_ctype and lc_messages? regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] 7.4beta1, Error in dumpall from 7.3.4 since CASCADE could not be used in REVOKE in 7.3.4
The following table was created in PostgreSQL 7.3.4 create table dummy_groupmember_is_admin (bemerkung varchar(20)); GRANT SELECT, UPDATE, INSERT ON dummy_groupmember_is_admin TO GROUP admin; REVOKE ALL ON dummy_groupmember_is_admin FROM cb,postgres; If I read in the dumpall from the PostgreSQL 7.3.4 database with PostgreSQL 7.4beta1 I get an error and the Hint that I should use CASCADE. The error line number points to: REVOKE ALL ON dummy_groupmember_is_admin FROM cb,postgres; But if I want to use CASCADE in PostgreSQL 7.3.4, I get a parse error. Indeed, the manual of 7.3.4 does only mention CASCADE with REVOKE in a note about SQL-92 compatibility, while the manual from 7.4beta1 shows that CASCADE is an optional part of the REVOKE command. Regards Christoph Becker ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[BUGS] 7.4beta4: make check broken?
Hi, the following configure/make batch with postgresql-7.4beta4 results with the error below. That is to say, make does work fine, but make check results in an error. Oviously the target-directory given with prefix is already used in some way with make check (when make install is not yet run). This error did not occur with 7.3 versions, where the make test seemed to restrict itself to the source directory and did not touch the target directory given by prefix. The OS is Suse 8.2 with bison updated to 1.85 as required because of a resp. warning from configure. SourceDir="/usr/local/src/postgresql-7.4beta4" TargetDir="/opt/doka/" PORTNR=5432 export [EMAIL PROTECTED] export LC_COLLATE=de_DE datum=`date +%d%b%Y_%H%M` make clean ./configure --prefix=$TargetDir/pgsql \ --enable-nls='de' \ --with-pgport=$PORTNR \ --with-tcl \ --with-odbc \ --with-perl \ --with-openssl \ --with-python make check This did result in the following ... == removing existing temp installation== == creating temporary installation== == initializing database system == == starting postmaster== running on port 65432 with pid 48 == creating database "regression" == /usr/local/src/postgresql-7.4beta4/src/test/regress/./tmp_check/install//opt/doka//pgsql/bin/createdb: relocation error: /us/local/src/postgresql-7.4beta4/src/test/regress/./tmp_check/install//opt/doka//pgsql/bin/createdb: undefined symbol: get_proname pg_regress: createdb failed make[2]: *** [check] Fehler 2 make[2]: Leaving directory `/usr/local/src/postgresql-7.4beta4/src/test/regress' make[1]: *** [check] Fehler 2 make[1]: Leaving directory `/usr/local/src/postgresql-7.4beta4/src/test' make: *** [check] Fehler 2 [EMAIL PROTECTED]:/usr/local/src/postgresql-7.4beta4> Regards Christoph Becker ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[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
[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
