[BUGS] BUG #4479: Incorrect TSearch2 results when inserting after deleting
The following bug has been logged online:
Bug reference: 4479
Logged by: Dan Fabulich
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.4
Operating system: OS X 10.5.5
Description:Incorrect TSearch2 results when inserting after deleting
Details:
Run the following psql script on Postgres 8.3.4. I've reproduced this on
Centos 5.2 and RhodiumToad on IRC reproduced the problem as well.
EXPECTED: The last two SELECT statements should return the same results (1
row)
ACTUAL: The final SELECT statement returns 0 results. The SELECT statement
just before it returns 1 result.
DROP DATABASE search_bug;
CREATE DATABASE search_bug;
\c search_bug
CREATE TABLE search_test (id bigserial PRIMARY KEY, name_search tsvector
default NULL, name_keywords varchar(255) default NULL);
CREATE INDEX name_search_index ON search_test USING gist(name_search);
create trigger name_search_update before update or insert on search_test for
each row execute procedure tsvector_update_trigger(name_search,
'pg_catalog.english', name_keywords);
SELECT * from search_test where name_search @@ to_tsquery('Noe');
-- should and does return nothing
INSERT INTO search_test (name_keywords) VALUES ('Noe Valley');
SELECT * from search_test where name_search @@ to_tsquery('Noe');
-- should and does return 1 row
DELETE from search_test where id = 1;
INSERT INTO search_test (name_keywords) VALUES ('Noe Valley');
SELECT * from search_test where name_search @@ to_tsquery('Noe');
-- should and does return 1 row
SELECT * from search_test where name_search @@ to_tsquery('Noe');
-- should return 1 row BUT RETURNS 0 ROWS; BUG!
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #4481: Big text insert/update using functions failed
The following bug has been logged online: Bug reference: 4481 Logged by: Julien Vadnais Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2.5 Operating system: Ubuntu Linux 7.04, Kernel 2.6.20-15-server Description:Big text insert/update using functions failed Details: Our actual configuration: PostgreSQL(libpq) Version : 8.2.4 Pdo : Module version 1.0.2 PHP : Version 5.2.6 When trying to insert/update long text string into the DB using a pgsql function, an error occures. (If ~6000 char or more) We have made several tests and we found that: -Insert/Update using pg-function and PDO failed -Insert/Update using PDO without pg-function works -Insert/Update using pg-function without PDO works -Insert/Update not using PDO and pg-function works This error was not occuring before we upgraded from postgresql-8.1.10. We tryed upgrading to postgresql-8.2.5 and postgresql-8.3.3 but the problem still occured in both of those versions. Here is the error we are catching on the DB server: SSL SYSCALL error: EOF detected could not receive data from client: Connection reset by peer unexpected EOF on client connection -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #4478: = operator in connection with CASE looks like loose some functionality (bug or feature?)
The following bug has been logged online: Bug reference: 4478 Logged by: Robert 'BoBsoN' Partyka Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3.4 Operating system: OpenSuSE Linux Description:= operator in connection with CASE looks like loose some functionality (bug or feature?) Details: Hi, I just migrate one application from 8.2.7 to 8.3.1, and I see some strange change of way the CASE works (case study tested also on 8.3.4). I have template system for sql queries which generates such sql: select * from foo where ind = case when '0''' then '0' else null end; it works slightly different in 8.2.7 and 8.3.4: test=# select * from foo; ind |inf -+--- 0 | Test info (1 row) version 8.2.7 test=# select version(); version -- PostgreSQL 8.2.7 on i686-pc-linux-gnu, compiled by GCC i686-pc-linux-gnu-gcc (GCC) 4.2.3 (Gentoo 4.2.3 p1.0) (1 row) test=# select * from foo where ind = case when '0''' then '0' else null end; ind |inf -+--- 0 | Test info (1 row) test=# select * from foo where ind = (case when '0''' then '0' else null end)::integer; ind |inf -+--- 0 | Test info (1 row) test=# select * from foo where ind = '0'; ind |inf -+--- 0 | Test info (1 row) As we see - all SQL are parsed ok, and executed without even notice or warning - but... version 8.3.4 test=# select version(); version - PostgreSQL 8.3.4 on x86_64-unknown-linux-gnu, compiled by GCC gcc (SUSE Linux) 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision 135036] (1 row) test=# select * from foo where ind = case when '0''' then '0' else null end; ERROR: operator does not exist: integer = text at character 29 HINT: No operator matches the given name and argument type(s). You might need to add explicit type casts. STATEMENT: select * from foo where ind = case when '0''' then '0' else null end; ERROR: operator does not exist: integer = text LINE 1: select * from foo where ind = case when '0''' then '0' els... ^ HINT: No operator matches the given name and argument type(s). You might need to add explicit type casts. test=# select * from foo where ind = (case when '0''' then '0' else null end)::integer; ind |inf -+--- 0 | Test info (1 row) test=# select * from foo where ind = '0'; ind |inf -+--- 0 | Test info (1 row) In construction ... ind = case ... automagic conversion from text to integer is not done anymore in 8.3.* - you must cast it manually. Is this bug or feature? (for me it looks like bug). If this is feature then I think it should be documented in manual and probably in some migration documentation. Regards - you do great job with PgSQL :) BoBsoN -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #4482: Segfault error 4
The following bug has been logged online: Bug reference: 4482 Logged by: manish singh Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3 Operating system: Centos 64bit Description:Segfault error 4 Details: Database Postgressql 8.3.3 is on clustering and replication and is patched by pgcluster 1.9.rc5.patch now this time this below error getting. we are running this setup from last 1 year having no error, this error meet us this month OCT 2008 kernel: postgres[4474]: segfault at 2b21b5f92004 rip 00536e10 rsp 780ec3c0 error 4 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #4488: jdbc : DatabaseMetaData.getPrimaryKeys no result
The following bug has been logged online: Bug reference: 4488 Logged by: Marcel Petavy Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2.4 Operating system: Windows XP Description:jdbc : DatabaseMetaData.getPrimaryKeys no result Details: Hi. If I try to query the primary key via JDBC driver postgresql-8.3-603.jdbc4.jar DatabaseMetaData.getPrimaryKeys I get not result. create table test (id integer not null primary key(id)) ResultSet rs = connection.getMetaData(null,null,test); rs gives no rows. All other known JDBC drivers (jtds MS-SQL, ojdbc16 Oracle) reporting the primary key id. Cya - Marcel -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Upgrade from 7.4.5 to 8.3.3
During an upgrade from 7.4.5 to 8.3.3 the following was dumped during the restore process from psql. psql:roperydb_v7.4_20081021.dmp:49: WARNING: could not determine encoding for locale C_C.C: codeset is DETAIL: Please report this to pgsql-bugs@postgresql.org. So I am reporting it. Back ground. I am using 8.3.3 because it is the latest I have for SCO OpenServer5.7 I used pg_dumpall -o from the 8.3.3 release. During the initdb process similar errors were dumped and a suggestion of passng a locale with the -E option was used. Explicitly I used: /usr/local/pgsql/bin/initdb -E SQL_ASCII -D /usr/local/pgsql/data which allowed the process to complete. The warning above was then dumped during the restore process. The cluster seems to working OK. Should I be concerned? Thanks for your time. Allan The material contained in this email may be confidential, privileged or copyrighted. If you are not the intended recipient, use, disclosure or copying of this information is prohibited. If you have received this document in error, please advise the sender and delete the document. Neither OneSteel nor the sender accept responsibility for any viruses contained in this email or any attachments. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4482: Segfault error 4
On Thu, Oct 16, 2008 at 10:33 AM, manish singh [EMAIL PROTECTED] wrote: The following bug has been logged online: Bug reference: 4482 Logged by: manish singh Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3 Operating system: Centos 64bit Description:Segfault error 4 Details: Database Postgressql 8.3.3 is on clustering and replication and is patched by pgcluster 1.9.rc5.patch now this time this below error getting. we are running this setup from last 1 year having no error, this error meet us this month OCT 2008 kernel: postgres[4474]: segfault at 2b21b5f92004 rip 00536e10 rsp 780ec3c0 error 4 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs If you're using pgcluster you'd do better reporting this to the pgcluster mailing lists - Josh / eggyknap -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4478: = operator in connection with CASE looks like loose some functionality (bug or feature?)
Robert 'BoBsoN' Partyka [EMAIL PROTECTED] writes: In construction ... ind = case ... automagic conversion from text to integer is not done anymore in 8.3.* - you must cast it manually. Is this bug or feature? (for me it looks like bug). It's intentional. If this is feature then I think it should be documented in manual and probably in some migration documentation. See the first item under the 8.3 migration caveats: Non-character data types are no longer automatically cast to TEXT http://www.postgresql.org/docs/8.3/static/release-8-3.html 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
Re: [BUGS] BUG #4481: Big text insert/update using functions failed
Julien Vadnais [EMAIL PROTECTED] writes: When trying to insert/update long text string into the DB using a pgsql function, an error occures. (If ~6000 char or more) People do that every day without problems. It sounds to me like you need to take this up with the authors of PDO (whatever that is). 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
Re: [BUGS] BUG #4488: jdbc : DatabaseMetaData.getPrimaryKeys no result
On Tue, 21 Oct 2008, Marcel Petavy wrote: Bug reference: 4488 PostgreSQL version: 8.2.4 Operating system: Windows XP Description:jdbc : DatabaseMetaData.getPrimaryKeys no result Details: If I try to query the primary key via JDBC driver postgresql-8.3-603.jdbc4.jar DatabaseMetaData.getPrimaryKeys I get not result. create table test (id integer not null primary key(id)) ResultSet rs = connection.getMetaData(null,null,test); rs gives no rows. It definitely does work, perhaps your table is really TEST instead of test? If you still believe it's a driver problem, please post a complete test case that shows the exact create table command and java code calling getPrimaryKeys. Kris Jurka -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4479: Incorrect TSearch2 results when inserting after deleting
Dan Fabulich [EMAIL PROTECTED] writes: Description:Incorrect TSearch2 results when inserting after deleting EXPECTED: The last two SELECT statements should return the same results (1 row) ACTUAL: The final SELECT statement returns 0 results. The SELECT statement just before it returns 1 result. Hmm. I can reproduce this with the given script on 8.3 current, but *not* in CVS HEAD. Also, the script results in an indexscan plan, but if you set enable_indexscan off (resulting in a bitmap scan of the same index), the correct result is returned. Fascinating. Teodor, will you look at this? 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
