[BUGS] Problems with UTF8 in PSQL
Hallo, I don't know if the problem has been reported yet, but it seems to have more implications. - Prerequisite: o PostgreSQL 8.1.4 on i486-pc-linux-gnu, compiled by GCC cc (GCC) 4.0.4 20060507 (prerelease) (Debian 4.0.3-3) o and psql o A database which was created with -E UTF8 - Description: If i log in into that database (client encoding is also in UTF8) a lot of "\"-commands are not accepted and the error message says "invalid byte sequence for UTF8" - Original output: test=> \d FEHLER: ungültige Byte-Sequenz für Kodierung »UTF8«: 0xfc6d6572220a test=> \q Same error message is in the log file -Implications? There are also problems in this field, if I try to add a constraint for a primary key from inside of another programming language with the same error message! So it could be a problem from PostqreSQL not from psql. HTH to find the problem Bye rolf ---(end of broadcast)--- TIP 6: explain analyze is your friend
[BUGS] BUG #2524: Error while using pg_restore command
The following bug has been logged online: Bug reference: 2524 Logged by: Sudarshan Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0 Operating system: Windoes-XP Description:Error while using pg_restore command Details: When i run the pg_restore command "pg_restore -d db1 -v -h localhost -p 5432 -U postgres db2.backup" I get the following error pg_restore: [archiver (db)] connection to database "db1" failed: FATAL: password authentication failed for user "postgres" I checked and rechecked the password and it seems correct. I also saw so many threads on "pg_restore" but could not find suitable answer for this. Ealiest help greatly appreciated. Cheers Sudarshan ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #2524: Error while using pg_restore command
> The following bug has been logged online: > > Bug reference: 2524 > Logged by: Sudarshan > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.0 > Operating system: Windoes-XP > Description:Error while using pg_restore command > Details: > > When i run the pg_restore command > > "pg_restore -d db1 -v -h localhost -p 5432 -U postgres db2.backup" > > I get the following error > > pg_restore: [archiver (db)] connection to database "db1" > failed: FATAL: > password authentication failed for user "postgres" > > I checked and rechecked the password and it seems correct. I > also saw so many threads on "pg_restore" but could not find > suitable answer for this. > > Ealiest help greatly appreciated. This looks like a bug that has been fixed in the latest versions in both the 8.0 and the 8.1 series. Upgrade to 8.0.8 or 8.1.4 and see if that fixes it. //Magnus ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] Problems with UTF8 in PSQL
Hello, When I experience the problem, the current Linux locale on my server is [EMAIL PROTECTED] Psql works fine if I change the current locale (by setting the LANG shell variable) to [EMAIL PROTECTED] I would be glad if psql may work fine without changing the LANG variable in the current session. Regards, Thomas rolf a écrit : Hallo, I don't know if the problem has been reported yet, but it seems to have more implications. - Prerequisite: o PostgreSQL 8.1.4 on i486-pc-linux-gnu, compiled by GCC cc (GCC) 4.0.4 20060507 (prerelease) (Debian 4.0.3-3) o and psql o A database which was created with -E UTF8 - Description: If i log in into that database (client encoding is also in UTF8) a lot of "\"-commands are not accepted and the error message says "invalid byte sequence for UTF8" - Original output: test=> \d FEHLER: ungültige Byte-Sequenz für Kodierung »UTF8«: 0xfc6d6572220a test=> \q Same error message is in the log file -Implications? There are also problems in this field, if I try to add a constraint for a primary key from inside of another programming language with the same error message! So it could be a problem from PostqreSQL not from psql. HTH to find the problem Bye rolf ---(end of broadcast)--- TIP 6: explain analyze is your friend -- Thomas REISS Ministère de l'Intérieur et de l'Aménagement du Territoire SG/DSIC/SCSIC/DESP/BSTN Tél. : 01-61-44-25-90 E-mail: [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[BUGS] BUG #2525: "No buffer space available" error running pg_dump on win2k for large bytea values
The following bug has been logged online: Bug reference: 2525 Logged by: Steve McWilliams Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.4 Operating system: Windows 2000 Description:"No buffer space available" error running pg_dump on win2k for large bytea values Details: We are having a problem with pg_dump that seems to be limited to windows 2000 platforms when we try to dump a db containing large bytea values. When I run pg_dump (options "-b -Fc -Z0") to dump the contents of a test database that isolates this problem I get the following error printed to the terminal: pg_dump: could not receive data from server: No buffer space available (0x2747/10055) pg_dump: SQL command to dump contents of table 'my_table' failed: PQendcopy() failed. pg_dump: Error message from server: could not receive data from server: No buffer space available (0x2747/10055) pg_dump: The command was: COPY public.my_table (my_id, my_array) TO stdout; The postmaster log file shows the following corresponding entry: LOG: could not receive data from client: No connection could be made because the target machine actively refused it. The database I am backing up here contains a single table. The table contains 2 columns, an integer id column and a bytea column. The table contains a single row with a bytea value containing 25.7 mb of binary data. If necessary I can send a dump of the db in question containing its schema and data (generated on linux). I am running postgres 8.1.4 on windows 2000 v5.00.2195 (srevice pack 4) on a pentium 4 2.6 ghz dedicated machine with 784 mb physical memory and 1.5 gb total virtual memory. The same machine is running both the postgres server and the pg_dump client, with nothing much else going on concurrently. I do not see the OS running out of resources during the pg_dump attempt (watching via TaskManager). We are not passing any options to postmaster at launch time other than the "-i" option to tell it to use tcp sockets, and we are using the default values in postgresql.conf. Note we are not able to reproduce this on windows xp pro or on windows 2003, or on linux. On windows 2k however it seems to always happen. A co-worker here reported this problem to pgsql-general several months ago. The relevent links are: http://archives.postgresql.org/pgsql-general/2006-01/msg00328.php http://archives.postgresql.org/pgsql-general/2006-01/msg00952.php http://archives.postgresql.org/pgsql-general/2006-01/msg00927.php At the time my co-worker thought he had worked around it by adding a sleep to the pg_dump read loop. This may have helped at the time (at the expense of making dumps take much much longer) I'm not sure, however recently the problem has returned so we need to find a better solution. As pointed out in one of the responses in the link above, the underlying problem seems to be that windows is returning a WSAENOBUFS error at some point during the transfer of data over the socket involved. The microsoft link referred to is: http://support.microsoft.com/kb/q201213 I'm not sure what the socket send/receive buffer sizes being used by postgres are. I tried hacking the postgres source where the sockets are created (both server and client sockets) to set their options to make sure they use buffer sizes less than 64k as suggested by microsoft, however that did not affect the problem. The tweakable registry entries referred to I am guessing are the same ones mentioned in another link I found when googling this problem: http://wiki.noreply.org/noreply/TheOnionRouter/WindowsBufferProblems I have not tried these registry tweaks yet, but from the description I don't think they would help because they pertain to WSAENOBUFS problems that occur when many sockets (5000+) are being used by the application, which is not the case here. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[BUGS] BUG #2526: records lost
The following bug has been logged online: Bug reference: 2526 Logged by: wee goh Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0.3-2 Operating system: linux Description:records lost Details: i discovered records in my postgresql database missing every 6 - 8 months. i supsect those not updated or amended are the ones that are gone, still wondering the real reason behind ? i doubt is lack of vaccum as my transactions are minnimal, inserting about 200 records each month and updating about 1000 records each month. this happens with previous versions of postgresql as well. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] bug report: recrods missing periodically
i discovered records in my postgresql database missing every 6 - 8 months. i supsect those not updated or amended are the ones that are gone, still wondering the real reason behind ? i doubt is lack of vaccum as my transactions are minnimal, inserting about 200 records each month and updating about 1000 records each month.this happens with previous versions of postgresql as well.Thu, 13 Jul 2006 6:00:43 (Singapore) Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail Beta.
Re: [BUGS] BUG #2526: records lost
On Wed, Jul 12, 2006 at 08:58:43PM +, wee goh wrote: > i discovered records in my postgresql database missing every 6 - 8 months. i > supsect those not updated or amended are the ones that are gone, still > wondering the real reason behind ? i doubt is lack of vaccum as my > transactions are minnimal, inserting about 200 records each month and > updating about 1000 records each month. How much querying are you doing? Are you vacuuming at all? What's the output of the following command? SELECT datname, age(datvacuumxid) AS vage, age(datfrozenxid) AS fage FROM pg_database; Do the server logs contain any unusual messages? Have you had any hardware problems or system crashes? -- Michael Fuhr ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
