Re: [BUGS] BUG #6105: Failed to load Main-Class manifest attribute
On 10/07/11 21:53, Jon C. wrote: > java -jar postgresql-8.4-702.jdbc3.jar > Failed to load Main-Class manifest attribute from > postgresql-8.4-702.jdbc3.jar What do you expect to happen? It's a JDBC driver, not a standalone program. You can't run it with "java -jar". It goes on the classpath so that Java programs can use it to connect to PostgreSQL. How to add it to the classpath depends on the Java software you are using. Check the manual for the software package you are attempting to use. The PgJDBC manual gives generic instructions for Java programmers. -- Craig Ringer -- 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 #6106: JAR File has no source attachment
On 11/07/2011 4:09 PM, Jonathan Camilleri wrote: I resolved this issue as I found the source code by looking on the Internet, excuse me. Great, thanks for letting me know. Good luck with your class / project. -- Craig Ringer POST Newspapers 276 Onslow Rd, Shenton Park Ph: 08 9381 3088 Fax: 08 9388 2258 ABN: 50 008 917 717 http://www.postnewspapers.com.au/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [HACKERS] [BUGS] make_greater_string() does not return a string in some cases
Thanks for your suggestion, I'll do so. At Fri, 8 Jul 2011 23:28:32 -0400, Robert Haas wrote: > Please add your patch to the next CommitFest. > > https://commitfest.postgresql.org/action/commitfest_view/open -- Kyotaro Horiguchi NTT Open Source Software Center -- 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 #6111: ftell mismatch error
The following bug has been logged online: Bug reference: 6111 Logged by: glum Email address: gene@rsa.com PostgreSQL version: 9.0 Operating system: Windows 7 Description:ftell mismatch error Details: I'm trying to dump a small database using the command line: pg_dump -Fc -Z9 I see a bunch of errors at the end: "ftell mismatch with expected position" I can use the same command on Unix without problem. In addition, using option "-Ft" works on the same platform. Any solution or suggestion for workaround will be appreciated. Thanks. -- 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 #6112: heuristic for empty parent tables that are members of inheritance trees
The following bug has been logged online: Bug reference: 6112 Logged by: Anish Kejariwal Email address: anish...@gmail.com PostgreSQL version: 9.0.3 Operating system: Linux Description:heuristic for empty parent tables that are members of inheritance trees Details: Hello, I'm filing this issue as a bug, and it seems like Tom Lane agrees that there is a bug, and said: " maybe we should reconsider the heuristic for tables that are members of inheritance trees --- particularly parents of inheritance trees." All information is in: http://archives.postgresql.org/pgsql-performance/2011-07/msg00063.php Scenario: -empty parent table -all data is in child/partitioned tables Bug: optimizer considers the parent table to be empty. Result: The execution plan is incorrect. My particularly query took 25 seconds with the wrong execution plan, but 0.3 seconds with the correct execution plan. Work around: Tom Lane suggested the following workaround to "defeat the empty-table heuristic: update pg_class set relpages = 1 where relname = 'icecream'; I'm using this work around for now, but I don't think this is acceptable. If someone were to accidentally run vacuum analyze on the parent table, then the relpages will be set back to zero, and the query will run slowly. Please let me know if you have any questions. Anish -- 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 #6111: ftell mismatch error
"glum" writes: > The following bug has been logged online: > Bug reference: 6111 > Logged by: glum > Email address: gene@rsa.com > PostgreSQL version: 9.0 > Operating system: Windows 7 > Description:ftell mismatch error > Details: > I'm trying to dump a small database using the command line: > pg_dump -Fc -Z9 > I see a bunch of errors at the end: > "ftell mismatch with expected position" Hmm, you certain you're using a 9.0.x pg_dump? Because this looks a lot like a problem that was fixed before that. If it is a current pg_dump, we're going to need to see a more complete test example. 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
[BUGS] application_name appears in Reporting and logging
I don't know but seems to be incorrect, it is really in this category? Version 9.1 beta 2 postgres=# select * from pg_settings where name = 'application_name'; -[ RECORD 1 ] name | application_name setting| psql unit | category | Reporting and Logging / What to Log short_desc | Sets the application name to be reported in statistics and logs. extra_desc | context| user vartype| string source | client -- -- Emanuel Calvo Helpame.com -- 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 #6081: trigger CRUD log entries, or documentation not clear that triggers do not log
Tom Hodder wrote: > > The following bug has been logged online: > > Bug reference: 6081 > Logged by: Tom Hodder > Email address: t...@limepepper.co.uk > PostgreSQL version: 8.4 > Operating system: Fedora 14 x86_64 > Description:trigger CRUD log entries, or documentation not clear > that triggers do not log > Details: > > with this log directive set; > log_statement = 'mod' > > I would expect that all CRUD statements would be logged to log_filename. > However CRUD statements called from trigger functions are not logged. > > This is unexpected, and does not reflect my reading of the documentation. log_statement only shows client-submitted queries, not function or trigger queries. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- 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 #6082: server segfault - pg_stat_reset_shared(null)
Steve Haslam wrote: > > The following bug has been logged online: > > Bug reference: 6082 > Logged by: Steve Haslam > Email address: araq...@googlemail.com > PostgreSQL version: 9.0.4 > Operating system: Debian GNU/Linux (amd64) > Description:server segfault - pg_stat_reset_shared(null) > Details: > > => select pg_stat_reset_shared(null) > *server segfault* > > Also occurs with a 9.1b2 build. > > To be fair, it *does* reset all the shared statistics. Now that's a RESET! ;-) -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- 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 #6085: pg_upgrade fails when unix_socket_directory != /tmp
This is caused by pg_ctl not properly understanding non-default socket directories --- this is fixed in Postgres 9.1. Not much pg_ctl can do to fix that except ignore a pg_ctl error return code, which isn't good. It will be fine in 9.1. --- Olivier LEVESQUE wrote: > > The following bug has been logged online: > > Bug reference: 6085 > Logged by: Olivier LEVESQUE > Email address: olevesq...@gmail.com > PostgreSQL version: 9.0.3 > Operating system: RHEL 5.4 Linux 2.6.18 x86_64 > Description:pg_upgrade fails when unix_socket_directory != /tmp > Details: > > Running pg_upgrade on clusters with unix_socket_directory parameter > different (e.g. /pgqdata/pgserver01/data) than default value (/tmp) fails: > > $ pg_upgrade -d /pgqdata/pgserver01/data -D /pgqdata/pgserver02/data -b > /opt/pgsql/na/8.4.4/bin -B /opt/pgsql/na/9.0.3/bin -p 5432 -P 5433 --check > Performing Consistency Checks > - > Checking old data directory (/pgqdata/pgserver01/data) ok > Checking old bin directory (/opt/pgsql/na/8.4.4/bin)ok > Checking new data directory (/pgqdata/pgserver02/data) ok > Checking new bin directory (/opt/pgsql/na/9.0.3/bin)ok > Trying to start old server > .ok > > Unable to start old postmaster with the command: > "/opt/pgsql/na/8.4.4/bin/pg_ctl" -l "/dev/null" -D > "/pgqdata/pgserver01/data" -o " -p 5432 -c autovacuum=off -c > autovacuum_freeze_max_age=20" start >> "/dev/null" 2>&1 > Perhaps pg_hba.conf was not set to "trust". > > > ===> Here, the error message given is not true, because old postmaster has > been started succesfuly. It is just the connection test that failed. > > A subsequent start (with old cluster running) of --check gives a better > information: > > PerForming Consistency Checks on Old Live Server > > Checking old data directory (/pgqdata/pgserver01/data) ok > Checking old bin directory (/opt/pgsql/na/8.4.4/bin)ok > Checking new data directory (/pgqdata/pgserver02/data) ok > Checking new bin directory (/opt/pgsql/na/9.0.3/bin)ok > Connection to database failed: could not connect to server: No such file or > directory > Is the server running locally and accepting > connections on Unix domain socket "/tmp/.s.PGSQL.5432"? > > ===> Why searching socket in /tmp while it is not the directory in > postgresql.conf? > > > Changing (commenting #unix_socket_directory in postgresql.conf) solves the > problem and pg_upgrade runs fine. > > -- > Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-bugs -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Window function bug
In branch postgresql/master: SELECT SUM(SUM(a)) OVER () FROM (SELECT NULL::int4 AS a WHERE FALSE) R; ERROR: XX000: cannot extract attribute from empty tuple slot Honestly, I'm not sure what the semantics of that are supposed to be. Is it even allowed by the standard? Regards, Jeff Davis -- 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] application_name appears in Reporting and logging
On Tuesday, July 12, 2011, Emanuel Calvo wrote: > I don't know but seems to be incorrect, it is really in this category? > > Version 9.1 beta 2 > > postgres=# select * from pg_settings where name = 'application_name'; > -[ RECORD 1 ] > name | application_name > setting | psql > unit | > category | Reporting and Logging / What to Log > short_desc | Sets the application name to be reported in statistics and logs. > extra_desc | > context | user > vartype | string > source | client > That is per design - why does it seem wrong? -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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 #6110: pg_hba.conf samehost does not work
The following bug has been logged online: Bug reference: 6110 Logged by: Binod Nepal Email address: nepalbi...@yahoo.com PostgreSQL version: 9.0.2 Operating system: Windows 7 Ultimate 32/64 Description:pg_hba.conf samehost does not work Details: pg_hba.conf # IPv4 local connections: hostall all 127.0.0.1/32md5 hostall all samehostmd5 hostall all samenetmd5 # IPv6 local connections: hostall all ::1/128 md5 hostall all samehostmd5 hostall all samenetmd5 postgresql.conf listen_addresses = '*' SYSTEM DETAILS Operating System Windows 7 Ultimate 32 or 64 bit Computer Name SERVER PostgreSQL Server Version PostgreSQL 9.0.2 BUG DESCRIPTION I am using pgAdminIII, trying create a "New Server Registration". When I connect to (localhost), it works fine. But when I change the host to the actual workstation name, it says: FATAL: no pg_hba.conf entry for host "fe80::c81c:9e9c:6570:d0bf%20", user "postgres", database "postgres", SSL off even when I have hostall all samehostmd5 on pg_hba.conf on IPv4 and IPv6 settings. PLEASE NOTE I am trying to connect to the server from the same machine. ADDITIONAL INFORMATION If I connect to "SERVER" from other computers on the same network, it works. For further information, please contact. -- 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 #6113: SET DATESTYLE='European' does not set datestyle output correctly
The following bug has been logged online: Bug reference: 6113 Logged by: David Carlos Manuelda Email address: stormb...@gmail.com PostgreSQL version: 9.0.4 Operating system: Gentoo Linux Description:SET DATESTYLE='European' does not set datestyle output correctly Details: According to Doc (http://www.postgresql.org/docs/7.2/static/sql-set.html), there are different datestyles available to format date outputs. But either is a bug in doc or is a bug in postgre itself, but 'European' does not currently do what it is intended (it does nothing actually). >From documentation: Testcase 1: OK German Use dd.mm. for numeric date representations. SET DATESTYLE='German'; SELECT NOW()::DATE; now 12.07.2011 Testcase 2: FAIL! SET DATESTYLE='European'; SELECT NOW()::DATE; now 12.07.2011 As you can see, SET DATESTYLE='European' just did nothing and did not change it from last set which was 'German', and of course, it does not even outputs what was expected and stated in documentation. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
