Re: [BUGS] BUG #2895: Private Use Unicode character crashes server when using ILIKE
On Tue, Jan 16, 2007 at 06:16:22AM +, James Russell wrote: > Description: Private Use Unicode character crashes server when using ILIKE The archives show that ILIKE is known to be broken with multibyte characters in 8.1 and earlier, although I don't recall seeing reports of a crash resulting. I got a crash in 8.1.6 built from the latest source in CVS; here's a partial stack trace: (gdb) bt #0 MBMatchTextIC (t=0x2a98613d1c "�\200\202\206", tlen=4, p=0x0, plen=4) at like_match.c:195 #1 0x005ae558 in texticlike (fcinfo=Variable "fcinfo" is not available. ) at like.c:355 I wonder if this is a problem only with code points outside of Plane 0, viz., those with UTF-8 sequences longer than three bytes. I don't get a crash with U+FFFD (E'\357\277\275') but I do with U+1 (E'\360\220\200\200') and other four-byte sequences. > - I have not yet tried to reproduce the bug on the latest Postgres 8.2.x It appears to work in 8.2.1; at least it didn't crash. The 8.2 Release Notes contain the following item: * Allow ILIKE to work for multi-byte encodings (Tom) Internally, ILIKE now calls lower() and then uses LIKE. Locale-specific regular expression patterns still do not work in these encodings. -- Michael Fuhr ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] BUG #2898: dynamic load support
Pankaj wrote: > > The following bug has been logged online: > > Bug reference: 2898 > Logged by: Pankaj > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.2.0 > Operating system: LynxOS > Description:dynamic load support > Details: > > I have installed Postgresql 8.2.0 on LynxOS. Although, LynxOS is an > unsupported OS platform, as per postgres docs, it should work on modern Unix > compatible OS. Lynx is a Unix-like RTOS. No, it shouldn't, unless you know something we don't. If LynxOS were 100% compatible with one of our supported platforms, it would run fine, but since it isn't, you are going to have to dig into why it is different and send us some patches to get LynxOS supported. --- > > When I run: > > /usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data > > It says: > fixing permissionsok > creating subdirectories...ok > selecting default max_connections...100 > selecting default shared_buffers/max_fsm_pages32MB/204800 > creating configuration filesok > creating template1 database.ok > initializing pg_authid.ok > initializing dependenciesok > creating system views...ok > loading system objects's dependencies...ok > creating conversionsFATAL: dynamic load not supported > STATEMENT: CREATE OR REPLACE FUNCTION... > > could not write to child process: Broken pipe > initdb: removing contents of data directory: /usr/local/pgsql/data > > Please let us know the cause of the above error. > > Thanks & regards, > Pankaj. > > ---(end of broadcast)--- > TIP 4: Have you searched our list archives? > >http://archives.postgresql.org -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] BUG #2848: information_schema.key_column_usage does not work
Laurence Rowe <[EMAIL PROTECTED]> writes:
>> I have the following query:
>>
>> SELECT key_column_usage.*,constraint_type
>> FROM information_schema.key_column_usage
>> LEFT JOIN information_schema.table_constraints USING
>> (table_schema,table_name,constraint_name)
>> WHERE table_schema='whatever' and table_name='whatever'
>> ORDER BY constraint_type, constraint_name, ordinal_position
>>
>> This works when I am logged on as 'postgres', but if I try it after logging
>> on with a different username it fails with "ERROR: relation with OID 18635
>> does not exist".
Hmph ... I recall being unable to reproduce this before, but I'm not
sure why I failed, because it's definitely broken. The key_column_usage
view has
FROM pg_namespace nr, pg_class r, pg_namespace nc,
pg_constraint c
WHERE nr.oid = r.relnamespace
AND r.oid = c.conrelid
AND nc.oid = c.connamespace
AND c.contype IN ('p', 'u', 'f')
AND r.relkind = 'r'
AND (NOT pg_is_other_temp_schema(nr.oid))
AND (pg_has_role(r.relowner, 'USAGE')
OR has_table_privilege(c.oid, 'SELECT')
OR has_table_privilege(c.oid, 'INSERT')
OR has_table_privilege(c.oid, 'UPDATE')
OR has_table_privilege(c.oid, 'REFERENCES')) ) AS ss
Obviously those last four lines should be r.oid not c.oid. The bug is
masked as long as the preceding pg_has_role() test succeeds, so in
particular a superuser would never see it :-(
We won't be able to force initdb to fix this in the back branches,
but fortunately the information schema views are not hardwired in.
Just drop the view and recreate it with the corrected definition...
regards, tom lane
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
Re: [BUGS] BUG #2901: missing alter table online help in psql
"Jens-Wolfhard Schicke" <[EMAIL PROTECTED]> writes: > \h alter table > is missing the syntax for the command > alter table the_table alter column the_column type varchar(175); Maybe you're using an old psql? My 8.2 psql shows regression=> \h alter table Command: ALTER TABLE Description: change the definition of a table Syntax: ALTER TABLE [ ONLY ] name [ * ] action [, ... ] ... where action is one of: ... ALTER [ COLUMN ] column TYPE type [ USING expression ] ... regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[BUGS] BUG #2901: missing alter table online help in psql
The following bug has been logged online: Bug reference: 2901 Logged by: Jens-Wolfhard Schicke Email address: [EMAIL PROTECTED] PostgreSQL version: PostgreSQL 8.2 Operating system: Linux Description:missing alter table online help in psql Details: \h alter table is missing the syntax for the command alter table the_table alter column the_column type varchar(175); ---(end of broadcast)--- TIP 6: explain analyze is your friend
[BUGS] BUG #2896: Dynamic loading
The following bug has been logged online: Bug reference: 2896 Logged by: Pankaj Srinivasan Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2.0 Operating system: LynxOS Description:Dynamic loading Details: I have been able to install PostgresSQL 8.2.0 on LynxOS. But when I run the inidb command as: /usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data It says: fixing permissionsok creating subdirectories...ok selecting default max_connections...100 selecting default shared_buffers/max_fsm_pages32MB/204800 creating configuration filesok creating template1 database.ok initializing pg_authid.ok initializing dependenciesok creating system views...ok loading system objects's dependencies...ok creating conversionsFATAL: dynamic load not supported STATEMENT: CREATE OR REPLACE FUNCTION... could not write to child process: Broken pipe initdb: removing contents of data directory: /usr/local/pgsql/data Please let us know the cause of the error. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[BUGS] BUG #2899: psql-odbc logging does not work for ordinary users
The following bug has been logged online: Bug reference: 2899 Logged by: Peter Hardman Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1 Operating system: Windows XP Pro Description:psql-odbc logging does not work for ordinary users Details: Checking MyLog on page 2 of Advanced Options for the PostgreSQL ANSI ODBC driver has no effect unless the user has write access to C:\. This prcludes logging for all ordinary users, and makes the logging facility mostly useless. I found a reference to this problem in psqlodbc-Bugs-1000522, where the developer seemed to assume that logging was not required by ordinary users. The logfile location should be configurable, or at least in the users TEMP directory as defined in the user's environment. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[BUGS] BUG #2895: Private Use Unicode character crashes server when using ILIKE
The following bug has been logged online:
Bug reference: 2895
Logged by: James Russell
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.4
Operating system: Linux (Fedora Core 5)
Description:Private Use Unicode character crashes server when using
ILIKE
Details:
A UTF-8 text field contains (among others) the following Unicode character:
0xf4808286 in UTF-8 (== 0x00100086 in UTF-32)
This corresponds to a character in the Unicode "Private Use" area, where the
codepoints are undefined and designated for proprietary uses
(0x10-0x10FFFD).
If a text field contains a such a character, and if the search term contains
certain Unicode characters, then queries using ILIKE will crash the server.
We discovered this bug when a user searched for rows containing the "TM"
character (UTF-8 0xE284A2 / UTF-32 0x2122), which translated to the
following query:
SELECT * FROM foo WHERE bar ILIKE('%â¢%');
If the rows searched contain the row with the Private Use character, then
the server crashes during the query and psql returns the following:
"psql:recreatebug.sql:8: server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
psql:recreatebug.sql:8: connection to server was lost"
This bug is 100% reproducible on multiple servers with different
configurations. Our server configuration does not have any changes from
default.
The following PHP script will generate a psql script that can reproduce the
problem. Run this script to generate the SQL script, then run the SQL script
in psql. The server will crash when the SELECT statement is run.
Re: [BUGS] BUG #2848: information_schema.key_column_usage does not work
I see the same problem with 8.2 on linux. Laurence Tony Marston wrote: The following bug has been logged online: Bug reference: 2848 Logged by: Tony Marston Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2 Operating system: Windows XP Description:information_schema.key_column_usage does not work Details: I have the following query: SELECT key_column_usage.*,constraint_type FROM information_schema.key_column_usage LEFT JOIN information_schema.table_constraints USING (table_schema,table_name,constraint_name) WHERE table_schema='whatever' and table_name='whatever' ORDER BY constraint_type, constraint_name, ordinal_position This works when I am logged on as 'postgres', but if I try it after logging on with a different username it fails with "ERROR: relation with OID 18635 does not exist". ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] BUG #2898: dynamic load support
"Pankaj" <[EMAIL PROTECTED]> writes: > creating conversionsFATAL: dynamic load not supported > STATEMENT: CREATE OR REPLACE FUNCTION... > Please let us know the cause of the above error. The encoding conversion code is all in dynamically-loaded libraries. (There are some other things that we expect to be able to load dynamically too, such as the various PL languages, but this happens to be what you'll hit first during initdb.) I think you probably need to add some code to src/backend/port/dynloader/ to support LynxOS. Please send a patch if you get it working. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
