Re: [GENERAL] WinNT installation problems - help please
I tried to run the Postgres.exe file but it complained about the version found being 7.0 and it requiring version 7.0 - huh? Look for the files called VERSION in the data directory and its descendants and convert them from windows text format to unix text format.
Re: [GENERAL] Redhat 7 and PgSQL
"Alfredo" [EMAIL PROTECTED] writes: I heard that MySQL is included in RH 7 instead of PgSQL. Is this true? No. Postgresql is included, and is the one installed when choosing "SQL Server" under the custom category. To get MySQL, you would have to install them manually afterwards, select "everything" or choose to manually select packages. Of course, we may switch the defaults in the future if we think MySQL is a better database in terms of upgradability, reliability, features and performance but there are no such plans right now. -- Trond Eivind Glomsrød Red Hat, Inc.
Re: [GENERAL] Redhat 7 and PgSQL
Not to mention the fact that PHP 4 installs with MySQL support native. If RedHat did do MySQL by default, technically Apache, PHP, and MySQL would be a pretty straightforward Web Serving bundle. Adam Lang Systems Engineer Rutgers Casualty Insurance Company - Original Message - From: "Trond Eivind Glomsrød" [EMAIL PROTECTED] To: "Alfredo" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, September 29, 2000 10:41 AM Subject: Re: [GENERAL] Redhat 7 and PgSQL "Alfredo" [EMAIL PROTECTED] writes: I heard that MySQL is included in RH 7 instead of PgSQL. Is this true? No. Postgresql is included, and is the one installed when choosing "SQL Server" under the custom category. To get MySQL, you would have to install them manually afterwards, select "everything" or choose to manually select packages. Of course, we may switch the defaults in the future if we think MySQL is a better database in terms of upgradability, reliability, features and performance but there are no such plans right now. -- Trond Eivind Glomsrød Red Hat, Inc.
Re: [GENERAL] Redhat 7 and PgSQL
"Alfredo" [EMAIL PROTECTED] 09/29/00 12:28PM I heard that MySQL is included in RH 7 instead of PgSQL. Is this true? if yes, anybody know why? i think the thing is that they added mysql because it's now GPL'd -- it wasn't in there before because it wasn't really "free" software. postgres (7.0.2) is indeed still in redhat 7, but with some of the comments on the list about the RPMs, it's possible that it may not stay as part of the distribution because of upgrading issues. -- Jeff Hoffmann PropertyKey.com
Re: [GENERAL] Talking with other Dbases.
Why not just have the application do both? You won't get the integrity of transactions, but mysql doesn't give you that anyway... ;-) Pardon me if I misunderstood what you were trying to do. Right now I'm just trying to do some preliminary planning, (hell, V1.0 isn't release JUST yet (day or so) :P) so I'm still kicking around some ideas about how I want to go about doing this. Maybe have a cron job that runs once every hour from the clients servers to update the central server. The data doesn't have to be realtime, but it would be nice to be somewhat up-to-date :). As for the clients writing to it, it's not necessary at all, and not really needed. The clients will have a server in thier lan, and the servers will be updating to the wan server :). But, I have a while before I start on V2.0, so for right now it's gathering info and running tests to see what works best. Thanks, | Daryl Chance | I have made this letter longer then | | Valuedata, LLC | usual because I lacked the time to | | Memphis, TN| make it shorter. -- Blaise Pascal |
Re: [GENERAL] reldesc does not exit
I have Postgres 7.0.2 installed on an Alpha running Red Hat Linux 6.2. The table is truncated and loaded with approximately 40,000 records per day. The load is done by performing a COPY FROM. The first time it was ever loaded, the load was done using insert statements, with autocommit on and the box froze half way through. Ever since then, every time the truncation is performed, the reldesc warning has been displayed. Currently this is just a demo version of the application, but the production version is planned to be rolled out within a month and the volume of records held in this table will eventually get up to 1 million. I added the definition of the table below. Any direction that you can give me to help me hunt this down is greatly appreciated. I am still pretty new at all of this. Thank you very much! Darrin CREATE TABLE foo ( barvarchar, last_category_cde varchar, last_bite_cnt int, last_page_cnt int, last_site_cntint, dtd_category_cde varchar, dtd_bite_cntint, dtd_page_cntint, dtd_site_cnt int, dtd_run_cntint, dtd_categ_1varchar, dtd_rating_1 int, dtd_categ_2varchar, dtd_rating_2 int, dtd_categ_3varchar, dtd_rating_3 int, wtd_category_cde varchar, wtd_bite_cnt int, wtd_page_cnt int, wtd_site_cnt int, wtd_run_cntint, wtd_categ_1varchar, wtd_rating_1 int, wtd_categ_2varchar, wtd_rating_2 int, wtd_categ_3varchar, wtd_rating_3 int, mtd_category_cde varchar, mtd_bite_cnt int, mtd_page_cnt int, mtd_site_cnt int, mtd_run_cntint, mtd_categ_1varchar, mtd_rating_1 int, mtd_categ_2varchar, mtd_rating_2 int, mtd_categ_3varchar, mtd_rating_3 int, tot_category_cde varchar, tot_bite_cnt int, tot_page_cnt int, tot_site_cnt int, tot_run_cntint, tot_categ_1varchar, tot_rating_1 int, tot_categ_2varchar, tot_rating_2 int, tot_categ_3varchar, tot_rating_3 int, last_bite_dte timestamp, added_dte timestamp, CONSTRAINT pk_foo PRIMARY KEY (bar) ); -Original Message- From: Tom Lane [EMAIL PROTECTED] To: Darrin Ladd [EMAIL PROTECTED] Cc: PGSQL General [EMAIL PROTECTED] Date: Friday, September 29, 2000 12:40 AM Subject: Re: [GENERAL] reldesc does not exit "Darrin Ladd" [EMAIL PROTECTED] writes: I continually get the following error when I truncate a very large table in my db: NOTICE: trying to delete a reldesc that does not exist Is this something that I should be concerned about? Possibly. That's a "shouldn't ever happen" kind of message, so it certainly indicates some sort of bug. Severity of bug is unguessable at this point. I don't see this when doing TRUNCATE on a plain-vanilla table, so I guess there is something special about your situation. What Postgres version are you running, on what platform? May we see the full definition of the table in question? Also, how large is "very large"? regards, tom lane
Re: [GENERAL] Redhat 7 and PgSQL
Trond Eivind Glomsrød wrote: "Alfredo" [EMAIL PROTECTED] writes: I heard that MySQL is included in RH 7 instead of PgSQL. Is this true? No. Postgresql is included, and is the one installed when choosing "SQL Server" under the custom category. To get MySQL, you would have to install them manually afterwards, select "everything" or choose to manually select packages. Not to mention that the MySQL packages are the GPL'd 3.23 _alpha_ code. Of course, we may switch the defaults in the future if we think MySQL is a better database in terms of upgradability, reliability, features and performance but there are no such plans right now. And PostgreSQL's reliability, features, and performance are sterling -- and the replication server being developed by PostgreSQL, Inc helps. But, upgradability is, well, almost nonexistant. No, dump/initdb/restore is not a real upgrade; it's a kludge (and doesn't necessarily work). I know one datamodel in particular that is currently having problems with databases restored from a pg_dump. We'll see if the 7.1 pg_dump helps. Currently, MySQL has us beat on the upgradability issue. And I cannot overemphasize how important a smooth upgrade is to a distribution maker like Red Hat. I am looking at the feasibility of the upgrade utility I mentioned a few weeks ago, and am finding it rough going. But, we'll see. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [GENERAL] Redhat 7 and PgSQL
Jeff Hoffmann [EMAIL PROTECTED] writes: "Alfredo" [EMAIL PROTECTED] 09/29/00 12:28PM I heard that MySQL is included in RH 7 instead of PgSQL. Is this true? if yes, anybody know why? i think the thing is that they added mysql because it's now GPL'd -- it wasn't in there before because it wasn't really "free" software. postgres (7.0.2) is indeed still in redhat 7, but with some of the comments on the list about the RPMs, it's possible that it may not stay as part of the distribution because of upgrading issues. I've never said or indicated that. That said, I dislike the current no-upgrade policy. -- Trond Eivind Glomsrød Red Hat, Inc.
Re: [GENERAL] Redhat 7 and PgSQL
Forgive my ignorance. What is this no-upgrade policy issue about? Jeff Hoffmann [EMAIL PROTECTED] writes: "Alfredo" [EMAIL PROTECTED] 09/29/00 12:28PM I heard that MySQL is included in RH 7 instead of PgSQL. Is this true? if yes, anybody know why? i think the thing is that they added mysql because it's now GPL'd -- it wasn't in there before because it wasn't really "free" software. postgres (7.0.2) is indeed still in redhat 7, but with some of the comments on the list about the RPMs, it's possible that it may not stay as part of the distribution because of upgrading issues. I've never said or indicated that. That said, I dislike the current no-upgrade policy. -- Trond Eivind Glomsrød Red Hat, Inc.
Re: [GENERAL] Redhat 7 and PgSQL
"Efrain Caro" [EMAIL PROTECTED] writes: Forgive my ignorance. What is this no-upgrade policy issue about? That you can't upgrade postgresql from e.g. 6.5 to 7.0 or from 7.0 to 7.1 Incidentally, you can dump data from a database. You can also insert data into a database. If you do this before and after upgrading, you'll hopefully have the same data in the database. -- Trond Eivind Glomsrød Red Hat, Inc.
Re: [GENERAL] reldesc does not exit
"Darrin Ladd" [EMAIL PROTECTED] writes: I have Postgres 7.0.2 installed on an Alpha running Red Hat Linux 6.2. The table is truncated and loaded with approximately 40,000 records per day. The load is done by performing a COPY FROM. The first time it was ever loaded, the load was done using insert statements, with autocommit on and the box froze half way through. Ever since then, every time the truncation is performed, the reldesc warning has been displayed. Hm. Nothing out-of-the-ordinary about your table definition or what you're doing with it, and 40K records is certainly not anything that's going to stress the system. An Alpha, on the other hand, is not such a common platform. I am thinking that there is probably some 64-bit portability bug lurking in the hashtable code that manages the reldesc cache. It might be dependent on the exact table name and/or OID. Could you tell us the real name of this table (I assume it's not "foo") and the OID (do "select oid from pg_class where relname = 'table name'")? Do you see the same notice when you do a TRUNCATE on other tables? Does anyone else running an Alpha see this sort of notice when doing a TRUNCATE TABLE? regards, tom lane
Re: [GENERAL] Redhat 7 and PgSQL
On 29 Sep 2000, Trond Eivind Glomsrød wrote: That you can't upgrade postgresql from e.g. 6.5 to 7.0 or from 7.0 to 7.1 Incidentally, you can dump data from a database. You can also insert data into a database. If you do this before and after upgrading, you'll hopefully have the same data in the database. FWIW, that's pretty tame compared to trying to migrate and upgrade an Oracle database. Have you ever seen some of the upgrade path rules for Oracle? If it's this version, first migrate to this version and then upgrade, but if it's this other version, then it can upgrade directly, unless it's the beta version, then you have to migrate blah blah blah... Is it feasible to create a 'universal installer' for PostgreSQL similar to what Oracle has (especially for binary distributions) that will do the data migration behind the scenes? Doing the source compile will probably require migrating the stuff manually (but if you are installing from source, you are doing everything manually *anyway*). Brett W. McCoy http://www.chapelperilous.net --- WHO sees a BEACH BUNNY sobbing on a SHAG RUG?!
Re: [GENERAL] Redhat 7 and PgSQL
"Efrain Caro" [EMAIL PROTECTED] writes: Forgive my ignorance. What is this no-upgrade policy issue about? It's not a "policy", it's just a problem: you usually can't update to a new major Postgres release without doing dump/initdb/reload. regards, tom lane
Re: [GENERAL] Redhat 7 and PgSQL
So we can say that we can upgrade, at least in theory, but that's not the official policy? - Original Message - From: [EMAIL PROTECTED] To: "Trond Eivind Glomsrød" [EMAIL PROTECTED] Cc: "Efrain Caro" [EMAIL PROTECTED]; "Jeff Hoffmann" [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, September 29, 2000 11:36 AM Subject: Re: [GENERAL] Redhat 7 and PgSQL On 29 Sep 2000, Trond Eivind Glomsrød wrote: That you can't upgrade postgresql from e.g. 6.5 to 7.0 or from 7.0 to 7.1 Incidentally, you can dump data from a database. You can also insert data into a database. If you do this before and after upgrading, you'll hopefully have the same data in the database. FWIW, that's pretty tame compared to trying to migrate and upgrade an Oracle database. Have you ever seen some of the upgrade path rules for Oracle? If it's this version, first migrate to this version and then upgrade, but if it's this other version, then it can upgrade directly, unless it's the beta version, then you have to migrate blah blah blah... Is it feasible to create a 'universal installer' for PostgreSQL similar to what Oracle has (especially for binary distributions) that will do the data migration behind the scenes? Doing the source compile will probably require migrating the stuff manually (but if you are installing from source, you are doing everything manually *anyway*). Brett W. McCoy http://www.chapelperilous.net --- WHO sees a BEACH BUNNY sobbing on a SHAG RUG?!
Re: [GENERAL] Re: JDBC Performance
Gunnar,
Your new JDBC driver (postgresql.jar, 29-Sept-2000, 14:47, 187K) caused
the following error.
Using these tables...
CREATE TABLE servers ( pid INT4 PRIMARY KEY, tableid INT2, host
TEXT, port INT4);
CREATE TABLE classes ( tableid INT2, classname TEXT, tablename
TEXT);
CREATE TABLE persistent ( pid INT4 PRIMARY KEY, tableid INT2);
CREATE TABLE test ( pid INT4 PRIMARY KEY, tableid INT2, my_string
TEXT, my_long INT8, my_double FLOAT8, ref INT8);
CREATE TABLE pids ( next_lpid INT4);
CREATE TABLE test2 ( pid INT4 PRIMARY KEY, tableid INT2, one INT4,
two INT2, three INT2, name TEXT, four FLOAT4, five FLOAT8, six INT8);
I run this select statement...
SELECT host, port FROM Servers WHERE PID=1;
Bad Integer int4
at org.postgresql.jdbc2.ResultSet.getInt(ResultSet.java:261)
at org.postgresql.jdbc2.ResultSet.getObject(ResultSet.java:748)
at org.postgresql.jdbc2.ResultSet.getObject(ResultSet.java:789)
at com.idisys.odb.ODBManager.loadMain(ODBManager.java:655)
at com.idisys.odb.ODBManager.load(ODBManager.java:584)
at com.idisys.odb.ODBManager.getObject(ODBManager.java:790)
at com.idisys.odb.ODBManager.getServer(ODBManager.java:814)
at com.idisys.odb.Reference.getServer(Reference.java:27)
at com.idisys.odb.Reference.getURL(Reference.java:39)
at com.idisys.odb.Test.test(Test.java:319)
at com.idisys.odb.Test.main(Test.java:124)
- Keith
-Original Message-
From: Gunnar R|nning [EMAIL PROTECTED]
To: Peter Mount [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED] [EMAIL PROTECTED]; PostgreSQL general mailing list
[EMAIL PROTECTED]; Keith L. Musser [EMAIL PROTECTED]
Date: Friday, September 29, 2000 9:08 AM
Subject: Re: [GENERAL] Re: JDBC Performance
Peter Mount [EMAIL PROTECTED] writes:
Email them to me, as the modifications will break when I commit my
changes
(delayed due to stress related illness), and there's a lot of changes
in
there. I'm about to resume work in a few minutes.
Okay, I wrapped up the modifications now. I'm appending the patch
against
the current CVS. You can also find the patch and a precompiled version
of
the driver at :
http://www.candleweb.no/~gunnar/projects/pgsql/
The interesting part is the replacement of new byte[] with an
allocByte()
method called that uses a pool of different byte arrays. I first tried
using the JDK 1.2 datastructures to implement the pooling, but they had
too
much overhead so I created a couple of simple and dirty implementations
instead.
I also added ReceiveString() methods that can take byte[] array as
parameter. All the ReceiveString methods in Connection now uses one
shared
byte array instead of forcing ReceiveString to allocate a new one on
each
call.
Comments and test results from others are very welcome.
Maybe I will look into doing the custom char conversion this weekend,
as
the default implementation provided by Sun appears to be the current
bottleneck. As Tim Kientzle wrote in another mail, this implementation
is
instatiating a new converter object every time you do a conversion.
This is
is also pointed out has a bottleneck by OptimizeIT.
Regards,
Gunnar
? postgresql.jar
? lazy_result.diff
? bytecache.diff
? org/postgresql/DriverClass.java
Index: org/postgresql/Connection.java
===
RCS file:
/home/projects/pgsql/cvsroot/pgsql/src/interfaces/jdbc/org/postgresql/Co
nnection.java,v
retrieving revision 1.6
diff -c -r1.6 Connection.java
*** org/postgresql/Connection.java 2000/09/12 05:09:54 1.6
--- org/postgresql/Connection.java 2000/09/29 12:54:12
***
*** 81,86
--- 81,91
// The PID an cancellation key we get from the backend process
public int pid;
public int ckey;
+
+ // This receive_sbuf should be used by the different methods
+ // that call pg_stream.ReceiveString() in this Connection, so
+ // so we avoid uneccesary new allocations.
+ byte receive_sbuf[] = new byte[8192];
/**
* This is called by Class.forName() from within
org.postgresql.Driver
***
*** 165,171
// "User authentication failed"
//
throw new SQLException(pg_stream.ReceiveString
!(4096, getEncoding()));
case 'R':
// Get the type of request
--- 170,176
// "User authentication failed"
//
throw new SQLException(pg_stream.ReceiveString
!(receive_sbuf, 4096,
getEncoding()));
case 'R':
// Get the type of request
***
*** 236,242
case 'E':
case 'N':
throw new SQLException(pg_stream.ReceiveString
! (4096, getEncoding()));
default:
throw new PSQLException("postgresql.con.setup");
}
--- 241,247
case 'E':
case 'N':
throw new SQLException(pg_stream.ReceiveString
!
Re: [GENERAL] Redhat 7 and PgSQL
On Fri, 29 Sep 2000, Efrain Caro wrote: So we can say that we can upgrade, at least in theory, but that's not the official policy? Well, I don't know about 'policy', but yes, you can upgrade PostgreSQL, you just need to dump your data first (which you should do anyway to backup -- never upgrade without backing up first!), install the upgrade by whatever method, do the initdb, then reload your data. It's a minor PITA, but it's also safe -- if you are doing a direct upgrade and it crashes or something else really bad happens, your database could get severely screwed. And then you're screwed. Brett W. McCoy http://www.chapelperilous.net --- Hoare's Law of Large Problems: Inside every large problem is a small problem struggling to get out.
Re: [GENERAL] Re: JDBC Performance
"Keith L. Musser" [EMAIL PROTECTED] writes: Gunnar, Your new JDBC driver (postgresql.jar, 29-Sept-2000, 14:47, 187K) caused the following error. Thanks, I will look into the problem. The regression tests that Peter Mount talking about would have been nice to have to catch things like this. You cannot by any chance send me a copy of your source code, so I have better chance of understanding and debugging the problem ? Regards, Gunnar
[GENERAL] pg_dump's over 2GB
My current backups made with pg_dump are currently 1.3GB. I am wondering what kind of headaches I will have to deal with once they exceed 2GB. What will happen with pg_dump on a Linux 2.2.14 i386 kernel when the output exceeds 2GB? Currently the dump file is later fed to a 'tar cvfz'. I am thinking that instead I will need to pipe pg_dumps output into gzip thus avoiding the creation of a file of that size. Does anyone have experince with this sort of thing? Bryan White, ArcaMax.com, VP of Technology You can't deny that it is not impossible, can you.
Re: [GENERAL] pg_dump's over 2GB
My current backups made with pg_dump are currently 1.3GB. I am wondering what kind of headaches I will have to deal with once they exceed 2GB. What will happen with pg_dump on a Linux 2.2.14 i386 kernel when the output exceeds 2GB? There are some ways around it if your program supports it, I'm not sure if it works with redirects... Currently the dump file is later fed to a 'tar cvfz'. I am thinking that instead I will need to pipe pg_dumps output into gzip thus avoiding the creation of a file of that size. Why not just pump the data right into gzip? Something like: pg_dumpall | gzip --stdout pgdump.gz (I'm sure that the more efficient shell scripters will know a better way) If your data is anything like ours, you will get at least a 5:1 compression ratio, meaning you can actually dump around 10 gigs of data before you hit the 2 gig file limit. steve
Re: [GENERAL] Redhat 7 and PgSQL
Well, I treat upgrading RedHat like I treat upgrading any OS... clean install. Adam Lang Systems Engineer Rutgers Casualty Insurance Company - Original Message - From: "Jeff Hoffmann" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, September 29, 2000 10:45 AM Subject: Re: [GENERAL] Redhat 7 and PgSQL "Alfredo" [EMAIL PROTECTED] 09/29/00 12:28PM I heard that MySQL is included in RH 7 instead of PgSQL. Is this true? if yes, anybody know why? i think the thing is that they added mysql because it's now GPL'd -- it wasn't in there before because it wasn't really "free" software. postgres (7.0.2) is indeed still in redhat 7, but with some of the comments on the list about the RPMs, it's possible that it may not stay as part of the distribution because of upgrading issues. -- Jeff Hoffmann PropertyKey.com
Re: [GENERAL] Redhat 7 and PgSQL
Tom Lane wrote: "Efrain Caro" [EMAIL PROTECTED] writes: Forgive my ignorance. What is this no-upgrade policy issue about? It's not a "policy", it's just a problem: you usually can't update to a new major Postgres release without doing dump/initdb/reload. The 'policy' is the lack of assigning developer time to fixing the problem. Smooth upgrades could easily be sold as a major feature. IMHO. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Fw: [GENERAL] Redhat 7 and PgSQL
I know you had to add the module for mysql for PHP 3, but I thought PHP 4 mysql was a native part. I compiled php 4 ad specifically asked for postgres support, while compiling, it mentioned how mysql APIs were being added any way (even though I did not tell it to). I'm sure it can be extracted, but it looks like the modules are a lot tighter together. So, in the php 4 RPM, you still need to add myql explicitly? Adam Lang Systems Engineer Rutgers Casualty Insurance Company - Original Message - From: "Trond Eivind Glomsrød" [EMAIL PROTECTED] To: "Adam Lang" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, September 29, 2000 10:53 AM Subject: Re: [GENERAL] Redhat 7 and PgSQL "Adam Lang" [EMAIL PROTECTED] writes: Not to mention the fact that PHP 4 installs with MySQL support native. While we have a MySQL module for PHP, we also have a pgsql module. If RedHat did do MySQL by default, technically Apache, PHP, and MySQL would be a pretty straightforward Web Serving bundle. So is Postgresql, PHP and Apache - no MySQL necesarry. -- Trond Eivind Glomsrød Red Hat, Inc.
Re: [GENERAL] pg_dump's over 2GB
Bryan White wrote: I am thinking that instead I will need to pipe pg_dumps output into gzip thus avoiding the creation of a file of that size. sure, i do it all the time. unfortunately, i've had it happen a few times where even gzipping a database dump goes over 2GB, which is a real PITA since i have to dump some tables individually. generally, i do something like pg_dump database | gzip database.pgz to dump the database and gzip -dc database.pgz | psql database to restore it. i've always thought that compress should be an option for pg_dump, but it's really not that much more work to just pipe the input and output through gzip. -- Jeff Hoffmann PropertyKey.com
Re: [GENERAL] pg_dump's over 2GB
On Fri, Sep 29, 2000 at 11:41:51AM -0500, Jeff Hoffmann wrote: Bryan White wrote: I am thinking that instead I will need to pipe pg_dumps output into gzip thus avoiding the creation of a file of that size. sure, i do it all the time. unfortunately, i've had it happen a few times where even gzipping a database dump goes over 2GB, which is a real PITA since i have to dump some tables individually. generally, i do something like pg_dump database | gzip database.pgz Hmm, how about: pg_dump database | gzip | split -b 1024m - database_ Which will give you 1GB files, named database_aa, database_ab, etc. to dump the database and gzip -dc database.pgz | psql database cat database_* | gunzip | psql database Ross Reedstrom -- Open source code is like a natural resource, it's the result of providing food and sunshine to programmers, and then staying out of their way. [...] [It] is not going away because it has utility for both the developers and users independent of economic motivations. Jim Flynn, Sunnyvale, Calif.
Re: [GENERAL] Redhat 7 and PgSQL
Trond Eivind Glomsrød writes: Incidentally, you can dump data from a database. You can also insert data into a database. If you do this before and after upgrading, you'll hopefully have the same data in the database. If there's a problem with pg_dump then pg_dump needs to be fixed, and incidentally, Philip Warner has been doing just that. But claiming that you can't upgrade is painting over what might rather be a deficiency in the RPM mechanism, ISTM. Why can't you have a spec file like this: %preupgrade pg_dumpall somewhere %postupgrade ... psql -f somewhere -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [GENERAL] Redhat 7 and PgSQL
Peter Eisentraut [EMAIL PROTECTED] writes: But claiming that you can't upgrade is painting over what might rather be a deficiency in the RPM mechanism, ISTM. Why can't you have a spec file like this: %preupgrade pg_dumpall somewhere 1) You don't know that postgresql is running. It probably isn't. 2) You don't know that you have the diskspace to do that. -- Trond Eivind Glomsrød Red Hat, Inc.
Re: [GENERAL] Re: JDBC Performance
"Keith L. Musser" [EMAIL PROTECTED] writes: Gunnar, Your new JDBC driver (postgresql.jar, 29-Sept-2000, 14:47, 187K) caused the following error. SELECT host, port FROM Servers WHERE PID=1; Bad Integer int4 at org.postgresql.jdbc2.ResultSet.getInt(ResultSet.java:261) at org.postgresql.jdbc2.ResultSet.getObject(ResultSet.java:748) at org.postgresql.jdbc2.ResultSet.getObject(ResultSet.java:789) OK, I found the problem. I will post a fixed version later today. The problem was that getObject() executed Field.getSQLType() which in turn executed Connection.ExecSQL(). I modified ExecSQL to deallocate the cached byte arrays on entry, because I believed it only were called by Statement.execute() methods. I guess I should move the deallocation into the Statement classes instead, as that is were it really belongs. I interpret the JDBC spec. to say that only one ResultSet will be open per. Statement, but one Connection canm have several statements with one result set each. Regards, Gunnar
[GENERAL] Re: postgresql
The mailing address in my address book (which is what I generally use): [EMAIL PROTECTED] The daily digests I get have the following email address at the top: [EMAIL PROTECTED] Both seem to work for me. - Tim Richard Brown wrote: Hi there, Sorry to bother you, I just picked you at random. I'm completely failing to be able to send emails to the postgres list and was just wondering what address you send your messages to, mayber I'm getting it wrong. I certainly don't see them on the list and I don't get any errors back. Thanks for your time, Richard.
Re: [GENERAL] Redhat 7 and PgSQL
On 29 Sep 2000, Trond Eivind Glomsrød wrote: But claiming that you can't upgrade is painting over what might rather be a deficiency in the RPM mechanism, ISTM. Why can't you have a spec file like this: %preupgrade pg_dumpall somewhere 1) You don't know that postgresql is running. It probably isn't. 2) You don't know that you have the diskspace to do that. These are things that have to be considered regardless of the upgrade mechanism. Brett W. McCoy http://www.chapelperilous.net --- What no spouse of a writer can ever understand is that a writer is working when he's staring out the window.
Re: Fw: [GENERAL] Redhat 7 and PgSQL
On Fri, 29 Sep 2000, Adam Lang wrote: I know you had to add the module for mysql for PHP 3, but I thought PHP 4 mysql was a native part. I compiled php 4 ad specifically asked for postgres support, while compiling, it mentioned how mysql APIs were being added any way (even though I did not tell it to). PHP 4.0 and up compile with MySQL support enabled by default - you have to specify --without-mysql when you run ./configure. I won't comment on the whole PHP being in bed with MySQL issue... -- Dominic J. Eidson "Baruk Khazad! Khazad ai-menu!" - Gimli --- http://www.the-infinite.org/ http://www.the-infinite.org/~dominic/
