[BUGS] Postgres Server Jdbc driver error
We get error with the following query where the paramater is 'att', the query return result if the parameter is different than 'att'. Probably a bug. the postgresql log is: 2011-08-04 10:44:56 CEST [28741]: [59238-1] LOG: execute S_1: BEGIN 2011-08-04 10:44:56 CEST [28741]: [59239-1] LOG: duration: 0.019 ms 2011-08-04 10:44:56 CEST [28741]: [59240-1] LOG: duration: 0.099 ms 2011-08-04 10:44:56 CEST [28741]: [59241-1] LOG: duration: 1.774 ms 2011-08-04 10:44:56 CEST [28741]: [59242-1] LOG: execute : select this_.trouble_ticket_id as y0_ from helpdesk.batch_sequences this_ where (this_.comment ilike $1 or this_.tech_note ilike $2) 2011-08-04 10:44:56 CEST [28741]: [59243-1] DETAIL: parameters: $1 = '%att%', $2 = '%att%' 2011-08-04 10:44:57 CEST [28741]: [59244-1] LOG: duration: 896.461 ms 2011-08-04 10:44:57 CEST [28741]: [59245-1] LOG: *incomplete message from client * 2011-08-04 10:44:57 CEST [28741]: [59246-1] LOG: disconnection: session time: 21:43:01.890 user=j01t02 database=webtng host=jblade01.sdb.it port=38173 On the Tomcat side we get followin message: Caused by: java.io.IOException: Tried to send an out-of-range integer as a 2-byte value: 34027 at org.postgresql.core.PGStream.SendInteger2(PGStream.java:201) at org.postgresql.core.v3.QueryExecutorImpl.sendParse(QueryExecutorImpl.java:1236) at org.postgresql.core.v3.QueryExecutorImpl.sendOneQuery(QueryExecutorImpl.java:1508) at org.postgresql.core.v3.QueryExecutorImpl.sendQuery(QueryExecutorImpl.java:1097) at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:255) Any comment higly appreciated -- Silvio Brandani --- Utilizziamo i dati personali che la riguardano esclusivamente per nostre finalità amministrative e contabili, anche quando li comunichiamo a terzi. Informazioni dettagliate, anche in ordine al Suo diritto di accesso e agli altri Suoi diritti, sono riportate alla pagina http://www.savinodelbene.com/privacy.html Se avete ricevuto questo messaggio per errore Vi preghiamo di ritornarlo al mittente eliminandolo assieme agli eventuali allegati, ai sensi art. 616 codice penale http://www.savinodelbene.com/privacy/codice_penale_616.html L'Azienda non si assume alcuna responsabilità giuridica qualora pervengano da questo indirizzo messaggi estranei all'attività lavorativa o contrari a norme. --
Re: [BUGS] [JDBC] Postgres Server Jdbc driver error
2011/8/4 Silvio Brandani : > On the Tomcat side we get followin message: > > > Caused by: java.io.IOException: Tried to send an out-of-range integer as a > 2-byte value: 34027 > at org.postgresql.core.PGStream.SendInteger2(PGStream.java:201) > at > org.postgresql.core.v3.QueryExecutorImpl.sendParse(QueryExecutorImpl.java:1236) > at > org.postgresql.core.v3.QueryExecutorImpl.sendOneQuery(QueryExecutorImpl.java:1508) > at > org.postgresql.core.v3.QueryExecutorImpl.sendQuery(QueryExecutorImpl.java:1097) > at > org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:255) What is the query that triggers this exception? (Not the one logged on the server side, it is the next query that's the problem) Taking the exception at face value implies that your query has 34,027 parameters, which seems somewhat unlikely (!!) unless you have a badly garbled query string. Oliver -- 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] [JDBC] Postgres Server Jdbc driver error
Il 04/08/2011 13.00, Oliver Jowett ha scritto: 2011/8/4 Silvio Brandani: On the Tomcat side we get followin message: Caused by: java.io.IOException: Tried to send an out-of-range integer as a 2-byte value: 34027 at org.postgresql.core.PGStream.SendInteger2(PGStream.java:201) at org.postgresql.core.v3.QueryExecutorImpl.sendParse(QueryExecutorImpl.java:1236) at org.postgresql.core.v3.QueryExecutorImpl.sendOneQuery(QueryExecutorImpl.java:1508) at org.postgresql.core.v3.QueryExecutorImpl.sendQuery(QueryExecutorImpl.java:1097) at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:255) What is the query that triggers this exception? (Not the one logged on the server side, it is the next query that's the problem) Taking the exception at face value implies that your query has 34,027 parameters, which seems somewhat unlikely (!!) unless you have a badly garbled query string. Oliver thanks for the support, we find the bug in the application , we will limt the number of parameters. -- Silvio Brandani --- Utilizziamo i dati personali che la riguardano esclusivamente per nostre finalità amministrative e contabili, anche quando li comunichiamo a terzi. Informazioni dettagliate, anche in ordine al Suo diritto di accesso e agli altri Suoi diritti, sono riportate alla pagina http://www.savinodelbene.com/privacy.html Se avete ricevuto questo messaggio per errore Vi preghiamo di ritornarlo al mittente eliminandolo assieme agli eventuali allegati, ai sensi art. 616 codice penale http://www.savinodelbene.com/privacy/codice_penale_616.html L'Azienda non si assume alcuna responsabilità giuridica qualora pervengano da questo indirizzo messaggi estranei all'attività lavorativa o contrari a norme. -- -- 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 #6147: Changing search_path between invocations of a function ignored by 2nd invocation of function
The following bug has been logged online: Bug reference: 6147 Logged by: Jim McQuillan Email address: j...@avairis.com PostgreSQL version: 9.0.4 Operating system: Ubuntu 10.04 x86 32 and 64 bit Description:Changing search_path between invocations of a function ignored by 2nd invocation of function Details: -- -- Calling a function twice, changing the schema search_path between calls -- The 2nd invocation doesn't notice the search_path has changed -- DROP SCHEMA IF EXISTS schema1 CASCADE; DROP SCHEMA IF EXISTS schema2 CASCADE; CREATE OR REPLACE FUNCTION public.test_func() RETURNS text AS $$ DECLARE result text; BEGIN SELECT value INTO result FROM test_table; RETURN result; END; $$ LANGUAGE plpgsql VOLATILE; CREATE SCHEMA schema1; CREATE SCHEMA schema2; CREATE TABLE schema1.test_table ( value text ); CREATE TABLE schema2.test_table ( value text ); INSERT INTO schema1.test_table ( value ) VALUES ( 'data from schema1' ); INSERT INTO schema2.test_table ( value ) VALUES ( 'data from schema2' ); SET search_path TO schema1; \echo 'calling test_func should result in "data from schema1"' SELECT public.test_func(); SET search_path TO schema2; \echo 'calling test_func should result in "data from schema2"' SELECT public.test_func(); I found reference to this problem in the todo list but it's from Jan 2008 and there was a suggestion of waiting until 8.4. Well... here we are with 9.0.4 and it doesn't seem to be getting any attention. I'm not complaining. I know everybody has more than enough things to work on. I just wanted to bring it up and see if anybody has had a chance to think about it. Given the choice between taking a performance hit for invalidating the cache versus getting unexpected results by not following the new search_path, I'd prefer the performance hit. To me, correct results is preferred over fast results any day. I've already worked around this problem by using EXECUTE but that only happened after a customer got pretty irritated with us because our software wasn't behaving the way they expected. btw, Postgresql rocks and you guys do awesome work. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Re: BUG #6120: Problem running post-install step in Mac OS X Lion (GM)
I have worked around this by adding the postgres user by hand: sudo dscl . -create /users/postgres sudo mkdir -p /usr/local/pgsql/data sudo chown postgres /usr/local/pgsql/data sudo dscl . -passwd /users/postgres su postgres chmod 755 /Library/PostgreSQL/9.0/bin/initdb su postgres /Library/PostgreSQL/9.0/bin/initdb -D /usr/local/pgsql/data (There is a predefined user in OS X Lion: "_postgres" but that's not the one the installer is expecting... ) -- View this message in context: http://postgresql.1045698.n5.nabble.com/BUG-6120-Problem-running-post-install-step-in-Mac-OS-X-Lion-GM-tp4598104p4665117.html Sent from the PostgreSQL - bugs mailing list archive at Nabble.com. -- 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 #6148: unterminated CSV quoted field
The following bug has been logged online: Bug reference: 6148 Logged by: william wei Email address: wei_jie...@founder.com PostgreSQL version: 8 Operating system: linux Description:unterminated CSV quoted field Details: error: unterminated CSV quoted field. when import CSV file. copy command: COPY tablename FROM '/tmp/test.cvs' csv DELIMITER AS ',' NULL AS '' QUOTE AS '"'; CVS file content: (error when value contains \") "value1 \" text ","value2","value3" -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Re: BUG #6120: Problem running post-install step in Mac OS X Lion (GM)
Thanks for the help with the adding the user... When I try to set up a new server with pgAdmin3 I get the message "Postgres not listening". What are the next steps to get Postgresql running a database? We at our firm never expected that postgresql installer would be deprecated this long -- View this message in context: http://postgresql.1045698.n5.nabble.com/BUG-6120-Problem-running-post-install-step-in-Mac-OS-X-Lion-GM-tp4598104p4665739.html Sent from the PostgreSQL - bugs mailing list archive at Nabble.com. -- 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 #6149: My table is empty but pg_relation_size(name) returns 39 MB
The following bug has been logged online:
Bug reference: 6149
Logged by: Shivakumar Ramannavar
Email address: shiv...@gmail.com
PostgreSQL version: 9.0.4
Operating system: open SUSE Linux
Description:My table is empty but pg_relation_size(name) returns 39
MB
Details:
Hi Team,
Though my table is empty, pg_relation_size(name) return 38 MB. I use below
query to determine tables disk usages.
SELECT nspname || '.' || relname AS "Table",
pg_total_relation_size(C.oid) "Size",
pg_size_pretty(pg_total_relation_size(C.oid)) AS "Total size"
FROM pg_class C
LEFT JOIN pg_namespace N ON (N.oid = C.relnamespace)
WHERE nspname NOT IN ('pg_catalog', 'information_schema')
AND C.relkind <> 'i'
AND nspname !~ '^pg_toast'
Please help,
Thanks!
Shiva
--
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 #6149: My table is empty but pg_relation_size(name) returns 39 MB
"Shivakumar Ramannavar" wrote: > Though my table is empty, pg_relation_size(name) return 38 MB. This is unlikely to be a bug, although without more information it's hard to be sure. Please post any follow-ups on the identical post you put on another list. And please don't cross-post like that. http://wiki.postgresql.org/wiki/Guide_to_reporting_problems -Kevin -- 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 #6150: commit_delay should have unit ms
The following bug has been logged online: Bug reference: 6150 Logged by: Christoph Anton Mitterer Email address: cales...@scientia.net PostgreSQL version: 0.9 Operating system: Debian sid Description:commit_delay should have unit ms Details: Hi. AFAIK form the documentation, the setting commit_delay, should have the base unit "ms". However, when doing something like $ psql -c 'SELECT name,vartype,unit FROM pg_settings;' | grep commit_delay I get: could not change directory to "/root/test" commit_delay| integer | No unit. Cheers, Chris. -- 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 #6151: documentation claims that default value for log_timezone is "unknown"
The following bug has been logged online: Bug reference: 6151 Logged by: Christoph Anton Mitterer Email address: cales...@scientia.net PostgreSQL version: 9.0 Operating system: Debian sid Description:documentation claims that default value for log_timezone is "unknown" Details: The documentation tells (http://www.postgresql.org/docs/9.0/static/runtime-config-logging.html#GUC-L OG-TIMEZONE) that the default for log_timezone is "unknown". It seems however that this is rather "localtime". (This possibly also appears in the default postgres.conf) Cheers, Chris. -- 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 #6151: documentation claims that default value for log_timezone is "unknown"
"Christoph Anton Mitterer" writes: > The documentation tells > (http://www.postgresql.org/docs/9.0/static/runtime-config-logging.html#GUC-L > OG-TIMEZONE) that the default for log_timezone is "unknown". That is technically correct, if not terribly helpful, in existing releases. 9.1 will be a bit cleaner in this regard, see http://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=1453cd8f8 http://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=2594cf0e8 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
