Re: [BUGS] Invalid EUC_JP char seq bug?
> >>search_words=%B7%F6%BA%7E > >>select id from products where name like '??~' > >>Query failed: ERROR: Invalid EUC_JP character sequence found (0xba7e) > > > > > > This is definitly a bad EUC_JP. > > According to a PHP developer in my bug report > (http://bugs.php.net/bug.php?id=24309&edit=2): > > "URL decoded byte sequance of 'search_words=%B7%F6%BA%7E' is > B7E6+BA7E, which is correct EUC-JP character sequence. [snip] But, I > believe encoding detection of mbstring works fine in this case. > B7E6+BA7E is not correct byte sequence of SJIS, UTF-8, ISO2022-JP. It is > correct EUC-JP byte sequence." > > I see that he wrote B7E6 instead of the correct B7F6. I resubmitted my > bug report to PHP and pointed this out. Hopefully the developer will see > that this sequence is incorrect EUC-JP and that PHP failed to detect this :) In the EUC_JP encoding there are some rules: 1) if the first byte is 0x8e then second byte is a JIS 0201 character and should be greater than 0x7f 2) else if the first byte is 0x8f then second and third byte is a JIS 0212 character and they should be greater than 0x7f 3) else if the first byte is greater than 0x7f then second and third byte is a JIS 0208 character and they should be greater than 0x7f 4) else the byte is ASII and should be eqaul to or less than 0x7f Apparently: B7F6: this is ok. we can apply rule #3 BA7E: this is not good, since it satisfies non of rule #1 to #4 > Thanks! > > Jean-Christian Imbeault > > PS I posted to HACKERS a few weeks ago about another bug (a real one :) > in the EUC-JP translation having to do with the WAVE DASH. I'll repost > here on the BUGS list, could you let me know the status of that BUG? Thanks! Sorry for the delay. In EUC-JP <--> Unicode translation, WAVE DASH is always a problem since there are several different mappings among different vendors/standards. I think I need more time to solve this. -- Tatsuo Ishii ---(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] 7.3.3 configure should check for curses before readline
The canned readline check assumes that curses is already installed. If it isn't then the readline check fails and configure reports that readline is not available. The real problem though is that curses is not available. -- Ian Grant, Computer Lab., William Gates Building, JJ Thomson Ave., Cambridge Phone: +44 1223 334420 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[BUGS] 7.3.3 ANALYZE problem (is it too bad?)
dynacom=# SELECT version(); version - PostgreSQL 7.3.3 on i686-pc-linux-gnu, compiled by GCC 2.96 (1 row) dynacom=# VACUUM ANALYZE ; ERROR: Unable to format timestamp with time zone; internal coding error dynacom=# VACUUM ; VACUUM dynacom=# ANALYZE ; ERROR: Unable to format timestamp with time zone; internal coding error Anyone knows whats going on?? -- == Achilleus Mantzios S/W Engineer IT dept Dynacom Tankers Mngmt Nikis 4, Glyfada Athens 16610 Greece tel:+30-210-8981112 fax:+30-210-8981877 email: achill at matrix dot gatewaynet dot com mantzios at softlab dot ece dot ntua dot gr ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] 7.3.3 ANALYZE problem (is it too bad?)
Also, % pg_dump -t noonmsg dynacom > noonmsg_dump.sql pg_dump: ERROR: Unable to format timestamp with time zone; internal coding error pg_dump: lost synchronization with server, resetting connection pg_dump: SQL command to dump the contents of table "noonmsg" failed: PQendcopy() failed. Also, # ANALYZE/pg_dump seems to work with other tables. Are there any thoughts on that? On Wed, 2 Jul 2003, Achilleus Mantzios wrote: > > dynacom=# SELECT version(); >version > - > PostgreSQL 7.3.3 on i686-pc-linux-gnu, compiled by GCC 2.96 > (1 row) > > dynacom=# VACUUM ANALYZE ; > ERROR: Unable to format timestamp with time zone; internal coding error > dynacom=# VACUUM ; > VACUUM > dynacom=# ANALYZE ; > ERROR: Unable to format timestamp with time zone; internal coding error > > > Anyone knows whats going on?? > -- == Achilleus Mantzios S/W Engineer IT dept Dynacom Tankers Mngmt Nikis 4, Glyfada Athens 16610 Greece tel:+30-210-8981112 fax:+30-210-8981877 email: achill at matrix dot gatewaynet dot com mantzios at softlab dot ece dot ntua dot gr ---(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
Was: Re: [BUGS] 7.3.3 ANALYZE problem
Finally i found the bad row in the bad table. My wondering is that a) java.sql.Timestamp.valueOf(String) accepts -MM-dd hh:mm:ss.fff b) when i try UPDATE noonmsg SET eta = '4714-01-01 BC'; i get ERROR: TIMESTAMP WITH TIME ZONE out of range '4714-01-01 BC' c) the girl who does data entry has no clue of what keys she pressed I am curious if this will happen to anyone again. On Wed, 2 Jul 2003, Achilleus Mantzios wrote: > > Also, > % pg_dump -t noonmsg dynacom > noonmsg_dump.sql > pg_dump: ERROR: Unable to format timestamp with time zone; internal > coding error > pg_dump: lost synchronization with server, resetting connection > pg_dump: SQL command to dump the contents of table "noonmsg" failed: > PQendcopy() failed. > > Also, > > # ANALYZE/pg_dump seems to work with other tables. > > Are there any thoughts on that? > > On Wed, 2 Jul 2003, Achilleus Mantzios wrote: > > > > > dynacom=# SELECT version(); > >version > > - > > PostgreSQL 7.3.3 on i686-pc-linux-gnu, compiled by GCC 2.96 > > (1 row) > > > > dynacom=# VACUUM ANALYZE ; > > ERROR: Unable to format timestamp with time zone; internal coding error > > dynacom=# VACUUM ; > > VACUUM > > dynacom=# ANALYZE ; > > ERROR: Unable to format timestamp with time zone; internal coding error > > > > > > Anyone knows whats going on?? > > > > -- == Achilleus Mantzios S/W Engineer IT dept Dynacom Tankers Mngmt Nikis 4, Glyfada Athens 16610 Greece tel:+30-210-8981112 fax:+30-210-8981877 email: achill at matrix dot gatewaynet dot com mantzios at softlab dot ece dot ntua dot gr ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[BUGS] 7.3.2: indexes on bigint field is not used for queries without quotas
Hi,
POSTGRESQL BUG REPORT
System Configuration
-
Architecture (example: Intel Pentium) : Intel Pentium III
Operating System (example: Linux 2.0.26 ELF) : FreeBSD 4.7
PostgreSQL version (example: PostgreSQL-7.3.2): PostgreSQL-7.3.2
Compiler used (example: gcc 2.95.2) : gcc 2.95.4
Please enter a FULL description of your problem:
Table "public.server"
Column | Type |Modifiers
+--+--
rec_id | bigint | not null default
nextval('next_server_id'::text)
Indexes: server_pkey primary key btree (rec_id),
...
Filed rec_id was upgraded from serial to serial8 by ALTER TABLE ...
commands. After this database was vacuumed, reindexer and analyzed.
After this performance get low dramaticaly. This due to foe queryes with
WHERE on filed rec_id with value without quotas do not use index
server_pkey.
this query do not use server_pkey index and it too slow.
search=# explain analyze select * from server where parent=12906;
QUERY PLAN
---
Seq Scan on server (cost=0.00..136.11 rows=1 width=91) (actual
time=2039.21..2039.21 rows=0 loops=1)
Filter: (parent = 12906)
Total runtime: 2039.62 msec
(3 rows)
but this query use server_pkey and it fast
search=# explain analyze select * from server where parent='12906';
QUERY PLAN
--
Index Scan using srv_parent on server (cost=0.00..6.04 rows=1
width=91) (actual time=199.96..199.96 rows=0 loops=1)
Index Cond: (parent = 12906::bigint)
Total runtime: 200.12 msec
(3 rows)
--
Maxim Zakharovhttp://www.maxime.net.ru/
Sochi, Russia http://sochi.org.ru/
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [BUGS] 7.3.3 ANALYZE problem (is it too bad?)
Achilleus Mantzios <[EMAIL PROTECTED]> writes: > dynacom=# VACUUM ANALYZE ; > ERROR: Unable to format timestamp with time zone; internal coding error Is it possible you have any really wacko timestamp values in your data? This looks like this recent report: http://fts.postgresql.org/db/msg.html?mid=1505105 but I dunno if it's the same problem. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] 7.3.3 ANALYZE problem (is it too bad?)
On Wed, 2 Jul 2003, Tom Lane wrote: > Achilleus Mantzios <[EMAIL PROTECTED]> writes: > > dynacom=# VACUUM ANALYZE ; > > ERROR: Unable to format timestamp with time zone; internal coding error > > Is it possible you have any really wacko timestamp values in your data? Thats right. The problem is that my app didnt get the wackoness, nor did the backend, and the data entry person doesnt remember exactly what wacking data did she enter the system. > This looks like this recent report: > http://fts.postgresql.org/db/msg.html?mid=1505105 > but I dunno if it's the same problem. > > regards, tom lane > > ---(end of broadcast)--- > TIP 6: Have you searched our list archives? > >http://archives.postgresql.org > -- == Achilleus Mantzios S/W Engineer IT dept Dynacom Tankers Mngmt Nikis 4, Glyfada Athens 16610 Greece tel:+30-210-8981112 fax:+30-210-8981877 email: achill at matrix dot gatewaynet dot com mantzios at softlab dot ece dot ntua dot gr ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: Was: Re: [BUGS] 7.3.3 ANALYZE problem
Achilleus Mantzios <[EMAIL PROTECTED]> writes: > Finally i found the bad row in the bad table. Were you able to determine what value was actually stored? (You might try using EXTRACT to get different parts of it.) regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[BUGS] Minor bug with syslog facility
PostgreSQL: 7.3.3 OS: Redhat 7.2 Changing the syslog facility (syslog_facility) in the configuration file has no effect after sending a SIGHUP to the postmaster. The only way to get the change is to restart the postmaster. Not sure whether this is a bug or it is suppose to behave this way. Certainly it is not documented as if though you need to do a restart. For example some setting have "This option must be set at server start". I know its not a biggie but its another one of those things that you can waste a lot of time on when you are following all the correct instructions... How to reproduce: Edit your /etc/syslog.conf file such that the messages log file filters out all local0 and local3 sources. e.g. *.info;mail.none;authpriv.none;cron.none;local3.none;local0.none /var/log/messages Add to the /etc/syslog.conf file the following lines local0.* /var/log/postgres0 local3.* /var/log/postgres3 save the file and do a SIGHUP on the syslogd process e.g. kill -HUP `cat /var/run/syslogd.pid` make sure postgreSQL logging is turned on and for this example also set log connections to true. e.g. edit the /var/lib/pgsql/data/postgresql.conf file (or the appropriate one according to your installation) such that log_connections = true syslog = 2 syslog_facility = 'LOCAL0' Do a SIGHUP on the postmaster. Make a connection to a database using some client software (psql will do). Drop the connection. View the log file /var/log/postgres0, it should have some entries like: Jul 2 20:27:45 CISX_Linux1 postgres[10848]: [1] LOG: Received SIGHUP, reloading configuration files Jul 2 20:29:14 CISX_Linux1 postgres[10957]: [2] LOG: connection received: host=192.168.100.22 port=2794 Jul 2 20:29:14 CISX_Linux1 postgres[10957]: [3] LOG: connection authorized: user=postgres database=template1 Jul 2 20:29:15 CISX_Linux1 postgres[10958]: [2] LOG: connection received: host=192.168.100.22 port=2795 Jul 2 20:29:15 CISX_Linux1 postgres[10958]: [3] LOG: connection authorized: user=postgres database=template1 Jul 2 20:29:17 CISX_Linux1 postgres[10959]: [2] LOG: connection received: host=192.168.100.22 port=2797 Jul 2 20:29:17 CISX_Linux1 postgres[10959]: [3] LOG: connection authorized: user=postgres database=Bugs Now edit the postgresql.conf file such that: syslog_facility = 'LOCAL3' Do a SIGHUP on the postmaster. Re-connect to a database again using some client software as before. Drop the connection. View the log file /var/log/postgres3, it should have the connection entries as in above but it doesn't! View the log file /var/log/postgres0, it has all the connections that occurred after editing the configuration file and doing a SIGHUP! e.g. Jul 2 20:27:45 CISX_Linux1 postgres[10848]: [1] LOG: Received SIGHUP, reloading configuration files Jul 2 20:29:14 CISX_Linux1 postgres[10957]: [2] LOG: connection received: host=192.168.100.22 port=2794 Jul 2 20:29:14 CISX_Linux1 postgres[10957]: [3] LOG: connection authorized: user=postgres database=template1 Jul 2 20:29:15 CISX_Linux1 postgres[10958]: [2] LOG: connection received: host=192.168.100.22 port=2795 Jul 2 20:29:15 CISX_Linux1 postgres[10958]: [3] LOG: connection authorized: user=postgres database=template1 Jul 2 20:29:17 CISX_Linux1 postgres[10959]: [2] LOG: connection received: host=192.168.100.22 port=2797 Jul 2 20:29:17 CISX_Linux1 postgres[10959]: [3] LOG: connection authorized: user=postgres database=Bugs Jul 2 20:36:48 CISX_Linux1 postgres[10848]: [2] LOG: Received SIGHUP, reloading configuration filesthese shouldn't have been here? Jul 2 20:37:01 CISX_Linux1 postgres[10969]: [3] LOG: connection received: host=192.168.100.22 port=3292 Jul 2 20:37:01 CISX_Linux1 postgres[10969]: [4] LOG: connection authorized: user=postgres database=template1 Jul 2 20:37:01 CISX_Linux1 postgres[10970]: [3] LOG: connection received: host=192.168.100.22 port=3293 Jul 2 20:37:01 CISX_Linux1 postgres[10970]: [4] LOG: connection authorized: user=postgres database=template1 Jul 2 20:37:05 CISX_Linux1 postgres[10971]: [3] LOG: connection received: host=192.168.100.22 port=3298 Jul 2 20:37:05 CISX_Linux1 postgres[10971]: [4] LOG: connection authorized: user=postgres database=Bugs Jul 2 20:37:07 CISX_Linux1 postgres[10972]: [3] LOG: connection received: host=192.168.100.22 port=3300 Jul 2 20:37:07 CISX_Linux1 postgres[10972]: [4] LOG: connection authorized: user=postgres database=CISX If you now restart the postmaster e.g. /etc/init.d/postgresql restart and now make a connection to the database as before you will find that all logging is going to the correct log file. That is the postmaster has updated and using the correct syslog facility setting as specified in the configuration file. Regards Donald Fraser.
[BUGS] Make install error
Title: Make install error Whenever I do a make install I get the following error: /usr/lib/postgresql/ascii_msc.so does not exist. Why?
Re: [BUGS] Problem with "z_" in Unicode-DB
On Wednesday 02 July 2003 00:37, Markus Bertheau wrote: > В Срд, 02.07.2003, в 00:27, Ian Barwick пишет: > > On Tuesday 01 July 2003 11:01, Wehrle, Daniel wrote: > > > Statement: > > > SELECT ID FROM tblAssets WHERE uri like > > > '/files/AssetStore/postgreSqlTest/ratz_ruebe.jpg' ; > > > > > > ERROR: Invalid UNICODE character sequence found (0xc000) > > > > > > Has PostgreSQL a problem with the characters "z_"? > > > > I would doubt it. Can you reproduce this problem with a > > different client, e.g. psql? I have tried using psql on 7.3.2 and 7.4a > > but see no problems. > > I can reproduce this with 7.3.3 using psql. I can't with 7.4devel. Hmm. Have just installed 7.3.3 from source but still cannot reproduce the problem. Any takers? Ian Barwick [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [BUGS] Problem with "z_" in Unicode-DB
В Срд, 02.07.2003, в 23:17, Ian Barwick пишет: > On Wednesday 02 July 2003 00:37, Markus Bertheau wrote: > > В Срд, 02.07.2003, в 00:27, Ian Barwick пишет: > > > On Tuesday 01 July 2003 11:01, Wehrle, Daniel wrote: > > > > Statement: > > > > SELECT ID FROM tblAssets WHERE uri like > > > > '/files/AssetStore/postgreSqlTest/ratz_ruebe.jpg' ; > > > > > > > > ERROR: Invalid UNICODE character sequence found (0xc000) > > > > > > > > Has PostgreSQL a problem with the characters "z_"? > > > > > > I would doubt it. Can you reproduce this problem with a > > > different client, e.g. psql? I have tried using psql on 7.3.2 and 7.4a > > > but see no problems. > > > > I can reproduce this with 7.3.3 using psql. I can't with 7.4devel. > > Hmm. Have just installed 7.3.3 from source but still cannot reproduce the > problem. Can you try to initdb in some UTF-8 locale? Then the following script triggers the error for me: create database unicodedebug with encoding='unicode'; \c unicodedebug create table a (a text); select * from a where a like 'z_'; I use gcc 3.2.2 and glibc 2.3.1. -- Markus Bertheau. Berlin, Berlin. Germany. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [BUGS] Make install error
Hello, Segree, Gareth wrote: Whenever I do a make install I get the following error: /usr/lib/postgresql/ascii_msc.so does not exist. Obvious, you have to install the ascii library before you can use postgres on your Nokia mobile phone. Regards // Bernd vdB ---(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] Minor bug with syslog facility
"Donald Fraser" <[EMAIL PROTECTED]> writes: > Changing the syslog facility (syslog_facility) in the configuration file ha= > s no effect after sending a SIGHUP to the postmaster. > The only way to get the change is to restart the postmaster. Probably so --- I think the syslog library will only examine those variables when first opening the syslog connection. You could change them on-the-fly if you'd not previously been using syslog. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
