[BUGS] Postgres 9 Installation problems
Hi, I updated PostgreSQL from 8.4.4 to 9.0.0 from repo (PGDG) via yum and it leaves some business unfinished IMHO. I have a Fedora Core FC12 (Linux 2.6.32.21-168.fc12.x86_64) up-to-date. So, after the upgrade, I found the following: a) The postgresql service is not present anymore, so I must start it by hand like this: sudo /etc/init.d/postgresql-9.0 start (and register the service by hand so that it does start with system startup). --> I expect the installer to install the system service into the list of services/daemons which are started at boot. b) The binaries (pg_dump, pg_restore, psql ...) of the new version are now in their own directory (/usr/pgsql-9.0/bin etc). The installer did not append a PATH entry to that new hierarchy or set the links to the binaries into /usr/bin. --> I expect a PATH entry to point to wherever the binaries are, or that there are links in /usr/bin c) pg_restore from PostgreSQL 9 apparently does not recognize compressed files generated by pg_dump from V 8.4.4 pg_restore V9 either said that the file was invalid, or it would just hang. I had to gunzip the dump by hand and then load it using psql. --> I expect pg_restore to work with a dump produced by pg_dump, or at least to tell me what is wrong. d) The new updated installation does not take over the settings (*.conf) from the previous one. Don't know if this is as designed so I decided to report it. Apart form that, thanks lots for the new PostgreSQL to everybody involved. Greetings from Vienna, RD
Re: [BUGS] Postgres 9 Installation problems
Hi, On Sat, 2010-09-25 at 12:21 +0200, r d wrote: > a) The postgresql service is not present anymore, so I must start it > by hand like this: sudo /etc/init.d/postgresql-9.0 start > (and register the service by hand so that it does start with system > startup). As of PostgreSQL 9.0, parallel installation is enabled, I mean, you will be able to install 9.1 along with 9.0 when it is released. So, init script name changed to reflect PostgreSQL version. > --> I expect the installer to install the system service into the list > ofervices/daemons which are started at boot. Nope. RPMs have never ever added PostgreSQL to startup sequence by default. > b) The binaries (pg_dump, pg_restore, psql ...) of the new version are > now in their own directory (/usr/pgsql-9.0/bin etc). Right, see above. > The installer did not append a PATH entry to that new hierarchy or set > the > links to the binaries into /usr/bin. > --> I expect a PATH entry to point to wherever the binaries are, or > that > there are links in /usr/bin Well, we used alternatives method for that: $ ls -l `which psql` /usr/bin/psql -> /etc/alternatives/pgsql-psql # ls -l /etc/alternatives/pgsql-psql /etc/alternatives/pgsql-psql -> /usr/pgsql-9.0/bin/psql However, we omitted that for some specific binaries like pg_ctl, which is pretty intentional. > c) pg_restore from PostgreSQL 9 apparently does not recognize > compressed files generated by pg_dump from V 8.4.4 > pg_restore V9 either said that the file was invalid, or it would just > hang. You need to take dump using 9.0's pg_dump so that you will be able to restore it... > d) The new updated installation does not take over the settings > (*.conf) from the previous one. > Don't know if this is as designed so I decided to report it. Right, RPMs don't do such interactive work. Regards, -- Devrim GÜNDÜZ PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer PostgreSQL RPM Repository: http://yum.pgrpms.org Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz signature.asc Description: This is a digitally signed message part
Re: [BUGS] Postgres 9 Installation problems
Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= writes: > On Sat, 2010-09-25 at 12:21 +0200, r d wrote: >> --> I expect the installer to install the system service into the list >> ofervices/daemons which are started at boot. > Nope. RPMs have never ever added PostgreSQL to startup sequence by > default. Right. Years ago I put out a version of the Red Hat Postgres RPMs that did do that, and was roundly chastized for it. An RPM is *not* supposed to assume that merely being installed means that the user wants it to start running a service. Otherwise, simply doing "install everything from the DVD" would be a disaster. 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] BUG #5678: libpq.so.4 is needed for pgadmin3
The following bug has been logged online: Bug reference: 5678 Logged by: faz Email address: fazal2...@gmail.com PostgreSQL version: 9.0 Operating system: CentOs Description:libpq.so.4 is needed for pgadmin3 Details: Hello, While i am trying to install Pgadmin3 after Postgresql 9.0 installed, it's always showing the following error/warning.Please help me. Resolving Dependencies There are unfinished transactions remaining. You might consider running yum-complete-transaction first to finish them. --> Running transaction check ---> Package pgadmin3.i386 0:1.8.4-1.el5.rf set to be updated --> Processing Dependency: libpq.so.4 for package: pgadmin3 --> Finished Dependency Resolution pgadmin3-1.8.4-1.el5.rf.i386 from rpmforge has depsolving problems --> Missing Dependency: libpq.so.4 is needed by package pgadmin3-1.8.4-1.el5.rf.i386 (rpmforge) Error: Missing Dependency: libpq.so.4 is needed by package pgadmin3-1.8.4-1.el5.rf.i386 (rpmforge) You could try using --skip-broken to work around the problem You could try running: package-cleanup --problems package-cleanup --dupes rpm -Va --nofiles --nodigest I had checked that , the libpq.so.5 is already located in the lib files of postgresql 9.0 , but no libpq.so.4. So how can i solve this problem? someone please help to do install pgadmin ! -- 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 #5678: libpq.so.4 is needed for pgadmin3
On Sat, 2010-09-25 at 10:23 +, faz wrote: > I had checked that , the libpq.so.5 is already located in the lib > files of postgresql 9.0 , but no libpq.so.4. So how can i solve this > problem? someone please help to do install pgadmin ! Which repository are you using? Only RPMForge? See below: > ---> Package pgadmin3.i386 0:1.8.4-1.el5.rf set to be updated You will need compat-postgresql-libs RPM, which is in pgrpms.org repo: http://yum.pgrpms.org/9.0/redhat/rhel-5-i386/repoview/compat-postgresql-libs.html If you are using this repo, yum will pick up compat package during dep check. -HTH. Regards, -- Devrim GÜNDÜZ PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer PostgreSQL RPM Repository: http://yum.pgrpms.org Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz signature.asc Description: This is a digitally signed message part
[BUGS] LEFT OUTER JOIN sub-SELECT produces a column != NULL when all NULLs are expected
Hi,
I found a bug where a column from a LEFT OUTER JOIN sub-SELECT is not
equal to NULL when the whole row must be NULL because the join condition
is not satisfied.
Here is the test case:
--
DROP TABLE IF EXISTS c;
DROP TABLE IF EXISTS b;
DROP TABLE IF EXISTS a;
CREATE TABLE a (
code CHAR NOT NULL,
CONSTRAINT a_pk PRIMARY KEY (code)
);
CREATE TABLE b (
a CHAR NOT NULL,
num INTEGER NOT NULL,
CONSTRAINT b_pk PRIMARY KEY (a, num),
CONSTRAINT b_a_fk FOREIGN KEY (a) REFERENCES a (code)
);
CREATE TABLE c (
name CHAR NOT NULL,
a CHAR,
CONSTRAINT c_pk PRIMARY KEY (name),
CONSTRAINT c_a_fk FOREIGN KEY (a) REFERENCES a (code)
);
INSERT INTO a (code) VALUES ('p');
INSERT INTO a (code) VALUES ('q');
INSERT INTO b (a, num) VALUES ('p', 1);
INSERT INTO b (a, num) VALUES ('p', 2);
INSERT INTO c (name, a) VALUES ('X', 'p');
INSERT INTO c (name, a) VALUES ('Y', 'q');
INSERT INTO c (name, a) VALUES ('Z', NULL);
SELECT c.name,
a.code,
a.b_cnt,
a.const
FROM c
LEFT OUTER JOIN (SELECT a.code,
COALESCE(b_grp.cnt, 0) AS b_cnt,
-1 AS const
FROM a
LEFT OUTER JOIN
(SELECT COUNT(1) AS cnt, b.a FROM b GROUP BY
b.a) AS b_grp
ON (a.code = b_grp.a)
) AS a ON (c.a = a.code)
ORDER BY c.name ASC;
--
This produces:
name | code | b_cnt | const
--+--+---+---
X| p| 2 |-1
Y| q| 0 |-1
Z| | 0 |-1
(3 rows)
The expected result is:
name | code | b_cnt | const
--+--+---+---
X| p| 2 |-1
Y| q| 0 |-1
Z| | |
(3 rows)
Tested under 8.4.4 and 9.0 (installed from Ubuntu packages).
Other database servers (SQLite, MySQL, Oracle, MS SQL Server) produce
the expected output.
Thanks,
Kirill
--
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] Mapping Hibernate boolean to smallint(Postgresql)
As a fundamental protocol, I prefer to keep any "attitudes" and "finger-pointing" off the table. Let us just focus on the real problem-solving. Though I am very versatile in speaking languages like C, C++ and Java, I assumed we all can speak and understand "English." You can also clearly see the issue on table is complicated. It spans Java, Hibernate, JDBC Drivers, RDBMS Engines and and finally people. Yes, the error is like - column "y" is of type integer but expression is of type boolean. I just expressed it in natural language "type mismatch." Below is the sample HBM file block. In the DB, DELETED column is SMALLINT but in the Java(POJOs), it is boolean. I like Dean's suggestion about "hibernate.query.substitutions." But does it really solve the issue? The current code (HBM mapping) is fully functional with Oracle (SMALLINT). That leaves us only two variables in the equation: 1. PostgresQL JDBC Driver 2. PostgresQL DB Engine. During my research on your JDBC discussion forum, I learned that JDBC team is mapping Java boolean to BIT or chars. Please refer this discussion. http://postgresql.1045698.n5.nabble.com/Wrong-SqlType-for-boolean-columns-td2256874.html#a2256874 Please refer to the following data type mapping between Java types and SQL types. Oracle: http://download.oracle.com/javase/1.3/docs/guide/jdbc/getstart/mapping.anc1.gif DB2: http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.ibm.db2.udb.doc/ad/rjvjdata.htm Is there any similar mapping reference for PostgresQL data types? (Seems this question was already raised and successfully ignored!) http://postgresql.1045698.n5.nabble.com/PostgreSQL-types-and-Java-types-td2174117.html ARE THERE ANY ALTERNATIVE (3rd-party) JDBC DRIVERs FOR POSTGRESQL? In this day & age compatibility with Hibernate got to be a key goal for any RDBMS. thanks. -- View this message in context: http://postgresql.1045698.n5.nabble.com/Mapping-Hibernate-boolean-to-smallint-Postgresql-tp2853280p2853928.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
Re: [BUGS] libpq: system-wide root.crt
On fre, 2010-09-24 at 09:50 +0200, Magnus Hagander wrote: > > I'm thinking, libpq could really use a global (and, for that matter, a > > per-user) configuration file, where you could set defaults for some of > > the things that you currently have to use environment variables for, > > e.g., sslmode. And then you can configure the system-wide root.crt > > location there. > > We already have this - pg_service.conf - no? Indeed. > > Alternatively, if you think that that is overkill, then using an > > environment variable to configure this feature would be consistent with > > the existing mechanisms. > > So in this case, a "sslfallbackroot=/etc/somewhere" parameter, that > you could then stick in etc/pg_service.conf, or in any of the other > places you can specify it? The one thing I think would be really > needed for that to work is to support wildcard database names in > pg_service.conf? Yes. -- 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 #5666: Pgadmin restore or back up database dont apper
On Mon, Sep 20, 2010 at 2:28 PM, Oscar Miguel Amezcua Estrella wrote: > > The following bug has been logged online: > > Bug reference: 5666 > Logged by: Oscar Miguel Amezcua Estrella > Email address: obel...@gmail.com > PostgreSQL version: 9.0.1 > Operating system: Opensuse 11.3 > Description: Pgadmin restore or back up database dont apper > Details: > > Hiyas im recent install PostgreSQL 9.0 in my pc im using a Gnu/Linux > Opensuse 11.3 and we try to restore my database in pgadmin buth it dont show > the option in database to restore :( we restore it in console :( this > problem onli in Gnu/Linux in windows it apper perfectly You might want to report this problem on the pgadmin list. http://archives.postgresql.org/pgadmin-support/ It might help to provide some more details. http://wiki.postgresql.org/wiki/Guide_to_reporting_problems http://www.postgresql.org/docs/current/static/bug-reporting.html -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
