[GENERAL] postgresql-9.0
Hi, In postgresql 9.0.4 i connected to a database and trying to make queries but i am facing memory issue, getting err as *glibc* detected *realloc* invalid next size so kindly requesting u to provide your valuable feed backs Regards Mehdi
Re: [GENERAL] postgresql-9.0
On 02/14/12 10:29 PM, khizer wrote: In postgresql 9.0.4 i connected to a database and trying to make queries but i am facing memory issue, getting err as *glibc* detected *realloc* invalid next size so kindly requesting u to provide your valuable feed backs insufficient information. * what OS? * what distribution of postgresql 9.0.4? (often there's multiple choices for a given OS), * history of this system? (did this used to work? if so, what changed?), * what mechanism are you using to make these queries? (psql shell, pgadmin3, application written in using language binding , etc etc). * etc etc. -- john r pierceN 37, W 122 santa cruz ca mid-left coast -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] postgresql-9.0
On Tue, Feb 14, 2012 at 11:29 PM, khizer khi...@srishtisoft.com wrote: Hi, In postgresql 9.0.4 i connected to a database and trying to make queries but i am facing memory issue, getting err as glibc detected realloc invalid next size so kindly requesting u to provide your valuable feed backs The first thing to figure out is if this is a client or server side issue. It's not uncommon to see folks do something like: psql mybigdb select * from somebigtable; and run out of memory on the client. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] PostgreSQL 9.0 and asynchronous replication through VPN
Indeed, there is a log message. My problem was that I missed to add "listen_address='*'" to my postgresql.conf! Hope this helps others in future. Regards, Edson Carlos Ericksson Richter SimKorp Informtica Ltda Fone: (51) 3366-7964 Celular: (51)9318-9766/(51) 8585-0796 Em 30-11-2011 14:41, Edson Richter escreveu: Em 30-11-2011 11:17, John DeSoi escreveu: On Nov 30, 2011, at 5:02 AM, Edson Richter wrote: I assume that the OpenVPN got disconnected for a few seconds, and came back again. My question is: assuming I have enough wal segments on Master side, does the Slave get synchronized automatically after the connection is reestablished, or I'll need to restart Slave PostgreSQL to put it in sync again? If I restart Slave PostgreSQL, I get: Yes, it automatically catches up when the connection is working again. You should not have to restart the slave. Thanks! Would be a nice improvement if when replication is restablished, then a log message occur. Regards, Edson. John DeSoi, Ph.D.
[GENERAL] PostgreSQL 9.0 and asynchronous replication through VPN
Dear friends, I have an somewhat unstable link between two different locations with OpenVPN established and working. Now, I've configured PostgreSQL 9.0.5 for asynchronous replication. This morning I got the following message on Slave PostgreSQL log: -- 2011-11-30 07:52:23 BRST % - FATAL: could not connect to the primary server: could not connect to server: Connection timed out Is the server running on host "10.68.73.5" and accepting TCP/IP connections on port 5432? 2011-11-30 07:55:33 BRST % - FATAL: could not connect to the primary server: could not connect to server: Connection timed out Is the server running on host "10.68.73.5" and accepting TCP/IP connections on port 5432? --- Detailed network configuration: PostgreSQL [Master = 10.68.73.5, Slave = 10.68.73.1]; OpenVPN [Server = 10.68.73.1; Client=10.68.73.5; both static IP] I assume that the OpenVPN got disconnected for a few seconds, and came back again. My question is: assuming I have enough wal segments on Master side, does the Slave get synchronized automatically after the connection is reestablished, or I'll need to restart Slave PostgreSQL to put it in sync again? If I restart Slave PostgreSQL, I get: -- 2011-11-30 08:01:09 BRST % - LOG: received fast shutdown request 2011-11-30 08:01:09 BRST % - FATAL: terminating walreceiver process due to administrator command 2011-11-30 08:01:09 BRST % - LOG: shutting down 2011-11-30 08:01:09 BRST % - LOG: database system is shut down 2011-11-30 08:01:18 BRST % - LOG: database system was shut down in recovery at 2011-11-30 08:01:09 BRST 2011-11-30 08:01:18 BRST % - LOG: entering standby mode 2011-11-30 08:01:18 BRST % - LOG: redo starts at A/420 2011-11-30 08:01:18 BRST % - LOG: record with zero length at A/4B0 -- Thanks for your help, -- Edson Carlos Ericksson Richter SimKorp Informtica Ltda Fone: (51) 3366-7964 Celular: (51)9318-9766/(51) 8585-0796
Re: [GENERAL] PostgreSQL 9.0 and asynchronous replication through VPN
On Nov 30, 2011, at 5:02 AM, Edson Richter wrote: I assume that the OpenVPN got disconnected for a few seconds, and came back again. My question is: assuming I have enough wal segments on Master side, does the Slave get synchronized automatically after the connection is reestablished, or I'll need to restart Slave PostgreSQL to put it in sync again? If I restart Slave PostgreSQL, I get: Yes, it automatically catches up when the connection is working again. You should not have to restart the slave. John DeSoi, Ph.D. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] PostgreSQL 9.0 and asynchronous replication through VPN
Em 30-11-2011 11:17, John DeSoi escreveu: On Nov 30, 2011, at 5:02 AM, Edson Richter wrote: I assume that the OpenVPN got disconnected for a few seconds, and came back again. My question is: assuming I have enough wal segments on Master side, does the Slave get synchronized automatically after the connection is reestablished, or I'll need to restart Slave PostgreSQL to put it in sync again? If I restart Slave PostgreSQL, I get: Yes, it automatically catches up when the connection is working again. You should not have to restart the slave. Thanks! Would be a nice improvement if when replication is restablished, then a log message occur. Regards, Edson. John DeSoi, Ph.D. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] PostgreSQL 9.0 or 9.1 ?
Hello again! (i got my traditional email-address back!) we have been running our infrastructure on 8.3 for quite some years now, and i am thinking it is now time to upgrade all major parts of our system (java, jboss, postgresql). I would tend to be a little radical and go a little optimistic and greedy about it. I have been using 9.0 as a test system with no major flaws for quite some time as well. (but unfortunately without exploiting any of its new features) Till the end of July i must have finished all the migration to the new versions. The migration will involve testing of about 5,458 sql statements and the migration of some heavily customized in house functions, including a version of DBmirror (which is in use for a very specific set of problems) So i am asking what would be better from your perspective to do? Go for 9.1? or stick to 9.0 and try to deploy it and take the most out of it? When is a stable (release) version of 9.1 be available? Has any one faced any issues migrating from 9.0 to 9.1 -- Achilleas Mantzios -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] PostgreSQL 9.0 or 9.1 ?
It could be worth considering 9.1. Probably by the time you get production ready version, 9.1 will be already stable (few months I guess). The usual answer to that question is - it will be ready when its ready. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] PostgreSQL 9.0 or 9.1 ?
On Thu, Jun 16, 2011 at 10:06 AM, Achilleas Mantzios ach...@matrix.gatewaynet.com wrote: Till the end of July i must have finished all the migration to the new versions. The migration will involve testing of about 5,458 sql statements and the migration of some heavily customized in house functions, including a version of DBmirror (which is in use for a very specific set of problems) You need to test these things on the exact version you plan to deploy, so not having a final 9.1 will make this pretty hard to do. Granted, the changes going in from now on are not supposed to be new/changed features, but just bug fixes... the final determination of how secure you feel in your testing is up to you. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] PostgreSQL 9.0 or 9.1 ?
-Original Message- From: pgsql-general-ow...@postgresql.org [mailto:pgsql-general- ow...@postgresql.org] On Behalf Of Grzegorz Jaskiewicz Sent: Thursday, June 16, 2011 11:05 AM To: Achilleas Mantzios Cc: pgsql-general@postgresql.org Subject: Re: [GENERAL] PostgreSQL 9.0 or 9.1 ? It could be worth considering 9.1. Probably by the time you get production ready version, 9.1 will be already stable (few months I guess). The usual answer to that question is - it will be ready when its ready. I would also ask, what is your (and your managements) tolerance for risk, and do you actually need any of the new features and/or performance benefits in 9.1? Postgres does have an excellent track record for quality and stability with new releases, but a couple of months in the field isn't really considered stable in most places. Brad. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] PostgreSQL 9.0 or 9.1 ?
Hello, we have been running our infrastructure on 8.3 for quite some years now, and i am thinking it is now time to upgrade all major parts of our system (java, jboss, postgresql). I would tend to be a little radical and go a little optimistic and greedy about it. I have been using 9.0 as a test system with no major flaws for quite some time as well. Till the end of July i must have finished all the migration to the new versions. The migration will involve testing of about 5,458 sql statements and the migration of some heavily customized in house functions, including a version of DBmirror (which is in use for a very specific set of problems) So i am asking what would be better by your perspective to do? Go for 9.1? or stick to 9.0? Where is a stable (release) version of 9.1 be available? Has any one faced any issues migrating from 9.0 to 9.1 Achilleas Mantzios
Re: [GENERAL] PostgreSQL 9.0 or 9.1 ?
On 06/16/2011 10:06 AM, Achilleas Mantzios wrote: Till the end of July i must have finished all the migration to the new versions. So i am asking what would be better from your perspective to do? Go for 9.1? or stick to 9.0 and try to deploy it and take the most out of it? When is a stable (release) version of 9.1 be available? Has any one faced any issues migrating from 9.0 to 9.1 I would place odds at about 1/3 that 9.1 will be available by the end of July. But you will still need to do testing of your application first before deploying onto that version. Realistically, even the earliest of 9.1 adopters is unlikely to launch before August. As such, there's not very much experience about the migration available yet, either. A large number of the new features in 9.1 aim at making certain types of development easier. The must-have features I am hearing demand for from my customers (who admittedly care more about replication and performance features than most), such that they are postponing some deployments until 9.1 ships because 9.0 just doesn't do what they want, are: -Synchronous replication -Support for MIN/MAX queries against partitioned tables -Feedback mechanism to reduce query conflict resolution when using Hot Standby -Much improved monitoring for replication and Hot Standby queries I'd suggest you take a look at the 9.1 release notes and beta announcement: http://www.postgresql.org/about/news.1313 , http://www.postgresql.org/docs/9.1/static/release-9-1.html And if you don't see a major compelling reason to wait for 9.1, some feature in that list that makes your life a lot easier, you really should just deploy 9.0 and move on. The most critical thing fixed in 9.1 development that may apply to what you're doing--some bug fixes to pg_upgrade--have all been backported to 9.0 now. -- Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us PostgreSQL 9.0 High Performance: http://www.2ndQuadrant.com/books -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] PostgreSQL 9.0 or 9.1 ?
On Thu, Jun 16, 2011 at 2:47 AM, Achilleas Mantzios mantzios.ach...@yahoo.com wrote: Hello, we have been running our infrastructure on 8.3 for quite some years now, and i am thinking it is now time to upgrade all major parts of our system (java, jboss, postgresql). I would tend to be a little radical and go a little optimistic and greedy about it. I have been using 9.0 as a test system with no major flaws for quite some time as well. Till the end of July i must have finished all the migration to the new versions. The migration will involve testing of about 5,458 sql statements and the migration of some heavily customized in house functions, including a version of DBmirror (which is in use for a very specific set of problems) So i am asking what would be better by your perspective to do? Go for 9.1? or stick to 9.0? Where is a stable (release) version of 9.1 be available? Has any one faced any issues migrating from 9.0 to 9.1 Are you looking for any features that 9.1 has to offer? If you aren't, it may make your decision easier. Unfortunately there are several 9.1 features that are just awesome. So, where you go from here is going to depend on your risk tolerance and (more importantly) your availability of testing resources. Testing of production-ish workloads during the beta period are very much appreciated by the community, so feel free to give it a shot as long as you understand the risk involved (which are substantial). One big risk with 9.1 early adoption is that you run the risk of having to dump/reload if you go production while in the before the build hits release candidate status (and sometimes, even then). So, if you are running a 24x7 duty cycle that's something to think about. merlin -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: Fw: [GENERAL] PostgreSQL 9.0 or 9.1 ?
Thanx, i think i'll just stick with 9.0 and try to take full advantage of it and when we are comfortable with all those features then move to 9.1 From: Merlin Moncure mmonc...@gmail.com To: Achilleas Mantzios mantzios.ach...@yahoo.com Cc: pgsql-general@postgresql.org pgsql-general@postgresql.org Sent: Thursday, June 16, 2011 7:12 PM Subject: Re: [GENERAL] PostgreSQL 9.0 or 9.1 ? On Thu, Jun 16, 2011 at 2:47 AM, Achilleas Mantzios mantzios.ach...@yahoo.com wrote: Hello, we have been running our infrastructure on 8.3 for quite some years now, and i am thinking it is now time to upgrade all major parts of our system (java, jboss, postgresql). I would tend to be a little radical and go a little optimistic and greedy about it. I have been using 9.0 as a test system with no major flaws for quite some time as well. Till the end of July i must have finished all the migration to the new versions. The migration will involve testing of about 5,458 sql statements and the migration of some heavily customized in house functions, including a version of DBmirror (which is in use for a very specific set of problems) So i am asking what would be better by your perspective to do? Go for 9.1? or stick to 9.0? Where is a stable (release) version of 9.1 be available? Has any one faced any issues migrating from 9.0 to 9.1 Are you looking for any features that 9.1 has to offer?� If you aren't, it may make your decision easier.� Unfortunately there are several 9.1 features that are just awesome.� So, where you go from here is going to depend on your risk tolerance and (more importantly) your availability of testing resources.� Testing of production-ish workloads during the beta period are very much appreciated by the community, so feel free to give it a shot as long as you understand the risk involved (which are substantial). One big risk with 9.1 early adoption is that you run the risk of having to dump/reload if you go production while in the before the build hits release candidate status (and sometimes, even then).� So, if you are running a 24x7 duty cycle that's something to think about. merlin -- Achilleas Mantzios -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] PostgreSQL 9.0 or 9.1 ?
Thanx brad, i think 9.0 would be the most wise decision for the time being. Στις Thursday 16 June 2011 18:29:16 γράψατε: -Original Message- From: pgsql-general-ow...@postgresql.org [mailto:pgsql-general- ow...@postgresql.org] On Behalf Of Grzegorz Jaskiewicz Sent: Thursday, June 16, 2011 11:05 AM To: Achilleas Mantzios Cc: pgsql-general@postgresql.org Subject: Re: [GENERAL] PostgreSQL 9.0 or 9.1 ? It could be worth considering 9.1. Probably by the time you get production ready version, 9.1 will be already stable (few months I guess). The usual answer to that question is - it will be ready when its ready. I would also ask, what is your (and your managements) tolerance for risk, and do you actually need any of the new features and/or performance benefits in 9.1? Postgres does have an excellent track record for quality and stability with new releases, but a couple of months in the field isn't really considered stable in most places. Brad. -- Achilleas Mantzios -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] PostgreSQL 9.0 users
Hi all, Could you please give us some typical users that already upgraded to version 9.0? We have a debate internally on choosing 8.4 or 9.0 as our product backend database. And if you have any performance benchmark result, I will highly appreciate. Many thanks, sheldon -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] PostgreSQL 9.0 users
Zhidong She zhidong@gmail.com writes: We have a debate internally on choosing 8.4 or 9.0 as our product backend database. Well, if it's about stability, a look at the commit logs will convince you that 9.0 and 8.4 branches are now about on par for bug fix rate. Since 9.0.4, I count 34 non-documentation patches applied to the 9.0 branch, and of these all but three were also patched in 8.4. Of those three, one was in a feature not available at all in 8.4 (walreceiver) and the other two were very minor bugs. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] PostgreSQL 9.0 users
I don't have bench marks but upgraded from 8.4 to 9.0 and it works perfect. No performance issues or problems but I highly recommend 9.0.4! On Jun 11, 2011 6:56 AM, Zhidong She zhidong@gmail.com wrote: Hi all, Could you please give us some typical users that already upgraded to version 9.0? We have a debate internally on choosing 8.4 or 9.0 as our product backend database. And if you have any performance benchmark result, I will highly appreciate. Many thanks, sheldon -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] PostgreSQL 9.0 users
Hey Zhidong, 2011/6/11 Zhidong She zhidong@gmail.com Hi all, Could you please give us some typical users that already upgraded to version 9.0? We have a debate internally on choosing 8.4 or 9.0 as our product backend database. We are switched our current development from 9.0 to 9.1 beta already without any doubts. And if you have any performance benchmark result, I will highly appreciate. Many thanks, sheldon -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general -- // Dmitriy.
[GENERAL] postgresql-9.0-801.jdbc4.jar always cause org.postgresql.util.PSQLException: Cannot commit when autoCommit is enabled Exception
Hello list, . Postgresql8.3 . mybatis-3.0.5-SNAPSHOT.jar . mybatis-spring-1.0.1-SNAPSHOT.jar . spring3.0.5 . postgresql-9.0-801.jdbc4.jar SqlSession sql_session = sqlSessionFactory.openSession(false); sql_session.commit(); Always got: === ### Error committing transaction. Cause: org.postgresql.util.PSQLException: Cannot commit when autoCommit is enabled. While for 8.4-702 JDBC 4, the same codes, no error at all. Is this a bug for postgresql-9.0-801.jdbc4.jar? Thanks a lot! Emi -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] postgresql-9.0-801.jdbc4.jar always cause org.postgresql.util.PSQLException: Cannot commit when autoCommit is enabled Exception
SqlSession sql_session = sqlSessionFactory.openSession(false); sql_session.commit(); We'll presume that you intend (intentionally or otherwise) for auto-commit to be on since you do not reference any actual JDBC method calls here... While for 8.4-702 JDBC 4, the same codes, no error at all. Is this a bug for postgresql-9.0-801.jdbc4.jar? Thanks a lot! Emi Arguably 8.4-702 was the bugged version and 9.0-801 corrects the behavior - or rather enforces the fact you should not be in auto-commit mode AND committing manually. Since this is a major version change such a behavioral change is to be expected. It should also at least be documented - but whether it is or not I do not know. I would recommend disabling auto-commit and leaving your commit() calls in place. You are generally much better off dealing with transaction logic explicitly instead of relying upon the driver to do it for you; though there are always exceptions but you should code is so that you can request an auto-commit session when you know you need one. David J. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] postgresql-9.0-801.jdbc4.jar always cause org.postgresql.util.PSQLException: Cannot commit when autoCommit is enabled Exception
David,
SqlSession sql_session = sqlSessionFactory.openSession(false);
sql_session.commit();
We'll presume that you intend (intentionally or otherwise) for auto-commit
to be on since you do not reference any actual JDBC method calls here...
I'd like always autocommit = false
jdbc8.4 does keep autocommit= false;
While 9.0 set default autocommit = true - this is NOT what I want.
Setup is in spring configuration file:
=
applicationContext-mybatis.xml
bean id=dataSource
class=org.springframework.jdbc.datasource.DriverManagerDataSource
property name=driverClassName value=${driverClassName} /
property name=url value=${url} /
property name=usernamevalue=${username} /
property name=passwordvalue=${password} /
/bean
mybatis does not have a parameter needed for autoCommit=false. The
default is false for JDBC8.4 driver.
While for 8.4-702 JDBC 4, the same codes, no error at all.
Arguably 8.4-702 was the bugged version and 9.0-801 corrects the behavior -
or rather enforces the fact you should not be in auto-commit mode AND
committing manually.
For Spring3.0.5 + mybatis3 + jdbc9, how do you setup autoCommit = false?
The default for 8.4 is false, while jdbc9 always get Cannot commit when
autoCommit is enabled Exception. Where should I specify autoCommit =
false for jdbc9 in spring frame work?
I would recommend disabling auto-commit and leaving your commit() calls in
place.
This is exactly what I had and I need for jdbc9 as well. But jdbc9
returns autoCommit = true ?
explicitly instead of relying upon the driver to do it for you; though there
are always exceptions but you should code is so that you can request an
auto-commit session when you know you need one.
Exactly.
I need to know in spring3.0.5 + mybatis + jdbc9 where to setup
autocommit= false.
For spring3.0.5 + mybatis + jdbc8, the default is autocommit = false.
Thank you,
Emi
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] postgresql-9.0-801.jdbc4.jar always cause org.postgresql.util.PSQLException: Cannot commit when autoCommit is enabled Exception
-Original Message- From: Emi Lu [mailto:em...@encs.concordia.ca] Sent: Tuesday, May 31, 2011 2:06 PM To: David Johnston Cc: pgsql-general@postgresql.org Subject: Re: [GENERAL] postgresql-9.0-801.jdbc4.jar always cause org.postgresql.util.PSQLException: Cannot commit when autoCommit is enabled Exception Exactly. I need to know in spring3.0.5 + mybatis + jdbc9 where to setup autocommit= false. For spring3.0.5 + mybatis + jdbc8, the default is autocommit = false. Thank you, Emi [Note: treat the following as pseudo code, i.e., the syntax may be incorrect] Don't know about the framework settings but since you seem to be wrapping your getConnection() and similar calls can you just modify your code to call connection.setAutoCommit(false) prior to returning the connection instance to the caller? You may want to ask (or search) on the appropriate framework list/faq since I would guess this question has been previously asked. The issue is not PostgreSQL specific so a PostgreSQL oriented list, even the JDBC one, may not yield someone who uses the framework in question. Even if you can setup the framework to default auto-commit if you are not already wrapping your getConnection() calls you'd be wise to consider doing so. If you want to toggle auto-commit on a per-request basis you would want to centralize that particular logic. I am not sure but you could also turn off auto-commit just before you execute() the statement if you are centralizing that part instead. I am not familiar with any of the persistence frameworks but your question HAS to have been asked and answered previously; it is just a matter of either finding the answer via search or waiting for someone more knowledgeable to respond. Otherwise you can at least ponder the alternatives (getConnection() or execute() centralization) which may be useful even if you find the more direct solution to this particular problem. David J. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] postgresql-9.0 service starting problem
Thanks to all. I found the wrong configuration in pg_hba.conf. The problem is solved. On Tue, Mar 29, 2011 at 8:02 PM, Raymond O'Donnell r...@iol.ie wrote: On 29/03/2011 14:59, Kalai R wrote: Hi, I am using Windows XP. When I have installed PostgreSQL 9.0.3, the service didn't start automatically. In the Computer Management I explicitly start postgresql-9.0 service, the service didn't start and following message displayed The postgresql-9.0 service on Local Computer started and then stopped. Some services stop automatically if they have no work to do, for example, the Performance Logs and Alerts Service What is the problem and How to solve it? Sounds like there was a problem look in the Postgres log, in the Windows event log, or both. Ray. -- Raymond O'Donnell :: Galway :: Ireland r...@iol.ie
[GENERAL] postgresql-9.0 service starting problem
Hi, I am using Windows XP. When I have installed PostgreSQL 9.0.3, the service didn't start automatically. In the Computer Management I explicitly start postgresql-9.0 service, the service didn't start and following message displayed The postgresql-9.0 service on Local Computer started and then stopped. Some services stop automatically if they have no work to do, for example, the Performance Logs and Alerts Service What is the problem and How to solve it? Thanks and Regards kalai
Re: [GENERAL] postgresql-9.0 service starting problem
On 29/03/2011 14:59, Kalai R wrote: Hi, I am using Windows XP. When I have installed PostgreSQL 9.0.3, the service didn't start automatically. In the Computer Management I explicitly start postgresql-9.0 service, the service didn't start and following message displayed The postgresql-9.0 service on Local Computer started and then stopped. Some services stop automatically if they have no work to do, for example, the Performance Logs and Alerts Service What is the problem and How to solve it? Sounds like there was a problem look in the Postgres log, in the Windows event log, or both. Ray. -- Raymond O'Donnell :: Galway :: Ireland r...@iol.ie -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] postgresql-9.0 service starting problem
Kalai, The postgresql-9.0 service on Local Computer started and then stopped. Some services stop automatically if they have no work to do, for example, the Performance Logs and Alerts Service most likely problem are unavailable ressources, as in: - PostgreSQL cannot access its data directory (because of changed file/directory permissions) - PostgreSQL cannot open its port for communication (because of other running PostgreSQL / because of zealous firewalls) or wrong configuration files, i.e. errors in pg_hba.conf or postgresql.conf. Start the eventview application and check for entries in the application log. Best wishes Harald -- Harald Armin Massa www.2ndQuadrant.com PostgreSQL Training, Services and Support 2ndQuadrant Deutschland GmbH GF: Harald Armin Massa Amtsgericht Stuttgart, HRB 736399
Re: [GENERAL] PostgreSQL 9.0 Streaming Replication Configuration
On Wed, Feb 09, 2011 at 01:14:05AM -0600, Ogden wrote: Thank you for letting me know about pg_controldata. I have been playing around with this tool. really interesting event/failure last night for me. I started a new thread on the failure in the admin list. my streaming rep without wal archiving in place seems to be corrupted. I think you will be interested in it. I could have tacked it on here, but I thought it needed to stand out. Regards, Ray -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] PostgreSQL 9.0 Streaming Replication Configuration
Hello all,
I have set up PostgreSQL Streaming Replication and all seems to work fine when
updating records as the records are instantaneously updated on the slave,
however, I was wondering perhaps if someone can give me some verification that
what I am doing is alright or some more insight into what I am doing. Perhaps
this will also help others in the future.
First on the master, I have the following in /var/lib/pgsql/data/standby.sh:
#!/bin/sh
LOG_FILE=/tmp/postgres_wal_archiving.log
log() { echo `date --rfc-3339=ns` $1 $LOG_FILE; }
log_error() { echo `date --rfc-3339=ns` $1 $LOG_FILE; exit 1; }
wal_path=$1
wal_file=$2
backup_server=slave01
remote_archive=/var/lib/pgsql/walfiles/$wal_file
log Transfering file to backup server, filename: $wal_file
rsync $wal_path $backup_server:$remote_archive
if [ $? -eq 0 ]; then
log Transfer to slave server completed
else
log_error Sending $wal_file failed.
fi
On the slave, I create the directory /var/lib/pgsql/walfiles (remote_archive)
for the script to copy the walfiles over to.
Then, within the master's postgresql.conf I have:
wal_level = hot_standby
archive_mode = on
archive_command = '/var/lib/pgsql/data/standby.sh %p %f /dev/null'# The
same script as above
archive_timeout = 30
max_wal_senders = 5
wal_keep_segments = 32
#hot_standby = off
I start up the master server and verify that files are indeed being SCPed over
to /var/lib/pgsql/walfiles (also processes shows: 'archiver process last was
00010003001E').
After starting up on the master, I rsync over the data/ directory to the slave:
/path/to/psql -c SELECT pg_start_backup('label', true)
rsync -avz --delete /var/lib/pgsql/data/ slave01:/var/lib/pgsql/data --exclude
postmaster.pid
/path/to/psql -c SELECT pg_stop_backup()
And I add recovery.conf over on the the slave's data/ directory:
standby_mode = 'on'
primary_conninfo = 'host=master_ip port=5432 user=postgres'
trigger_file = '/tmp/trigger'
restore_command='cp /var/lib/pgsql/walfiles/%f %p'
And in the slave's postgresql.conf, I remove the comment on :
hot_standby = on
Upon starting the slave, everything works fine and updates to records occur on
the slave immediately (what is the actual timing for this)?
My confusion is: does streaming replication require WAL archiving as I have
illustrated above or is it a just in case scenario? Also, the restore_command
on the slave - is this correct, assuming that the master is dropping off files
via SCP to /var/lib/pgsql/walfiles ?
Thank you very much
Ogden Nefix
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] PostgreSQL 9.0 Streaming Replication Configuration
pg_controldata command is helpful.
Archiving wal not required, but you can roll it either way.
On Tue, Feb 08, 2011 at 04:46:51PM -0600, Ogden wrote:
Hello all,
I have set up PostgreSQL Streaming Replication and all seems to work fine
when updating records as the records are instantaneously updated on the
slave, however, I was wondering perhaps if someone can give me some
verification that what I am doing is alright or some more insight into what I
am doing. Perhaps this will also help others in the future.
First on the master, I have the following in /var/lib/pgsql/data/standby.sh:
#!/bin/sh
LOG_FILE=/tmp/postgres_wal_archiving.log
log() { echo `date --rfc-3339=ns` $1 $LOG_FILE; }
log_error() { echo `date --rfc-3339=ns` $1 $LOG_FILE; exit 1; }
wal_path=$1
wal_file=$2
backup_server=slave01
remote_archive=/var/lib/pgsql/walfiles/$wal_file
log Transfering file to backup server, filename: $wal_file
rsync $wal_path $backup_server:$remote_archive
if [ $? -eq 0 ]; then
log Transfer to slave server completed
else
log_error Sending $wal_file failed.
fi
On the slave, I create the directory /var/lib/pgsql/walfiles (remote_archive)
for the script to copy the walfiles over to.
Then, within the master's postgresql.conf I have:
wal_level = hot_standby
archive_mode = on
archive_command = '/var/lib/pgsql/data/standby.sh %p %f /dev/null'# The
same script as above
archive_timeout = 30
max_wal_senders = 5
wal_keep_segments = 32
#hot_standby = off
I start up the master server and verify that files are indeed being SCPed
over to /var/lib/pgsql/walfiles (also processes shows: 'archiver process
last was 00010003001E').
After starting up on the master, I rsync over the data/ directory to the
slave:
/path/to/psql -c SELECT pg_start_backup('label', true)
rsync -avz --delete /var/lib/pgsql/data/ slave01:/var/lib/pgsql/data
--exclude postmaster.pid
/path/to/psql -c SELECT pg_stop_backup()
And I add recovery.conf over on the the slave's data/ directory:
standby_mode = 'on'
primary_conninfo = 'host=master_ip port=5432 user=postgres'
trigger_file = '/tmp/trigger'
restore_command='cp /var/lib/pgsql/walfiles/%f %p'
And in the slave's postgresql.conf, I remove the comment on :
hot_standby = on
Upon starting the slave, everything works fine and updates to records occur
on the slave immediately (what is the actual timing for this)?
My confusion is: does streaming replication require WAL archiving as I have
illustrated above or is it a just in case scenario? Also, the
restore_command on the slave - is this correct, assuming that the master is
dropping off files via SCP to /var/lib/pgsql/walfiles ?
Thank you very much
Ogden Nefix
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] PostgreSQL 9.0 Streaming Replication Configuration
On Feb 8, 2011, at 8:47 PM, Ray Stell wrote: pg_controldata command is helpful. Archiving wal not required, but you can roll it either way. That is my confusion - Archiving wal does not conflict in any way with streaming replication? What if streaming replication lags behind (especially with a lot of connections). Thank you Ogden -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] PostgreSQL 9.0 Streaming Replication Configuration
If the standby server cannot pull the WAL file from the master using streaming replication, then it will attempt to pull it from the archive. If the WAL segment isn't archived (for example because you aren't using archiving), then your streaming replication is unrecoverable and you have to take a fresh backup from the master and transfer it over to the standby machine to start replication again. So the value of having archiving setup is that in case a standby falls way behind, then the standby can recover without having to copy your database over to the standby machine again. Another setting you can tweak is wal_keep_segments on the master machine, which is the minimum numbers of WAL segments it will keep without deleting. So just with some simple math: (wal_keep_segments * 16MB / your_wal_write_rate) you can determine a ballpark of how long your standby machines can fall behind while still being able to recover without archiving. -Dan On Tue, Feb 8, 2011 at 6:51 PM, Ogden li...@darkstatic.com wrote: On Feb 8, 2011, at 8:47 PM, Ray Stell wrote: pg_controldata command is helpful. Archiving wal not required, but you can roll it either way. That is my confusion - Archiving wal does not conflict in any way with streaming replication? What if streaming replication lags behind (especially with a lot of connections). Thank you Ogden -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] PostgreSQL 9.0 Streaming Replication Configuration
On Tue, Feb 08, 2011 at 08:51:42PM -0600, Ogden wrote: On Feb 8, 2011, at 8:47 PM, Ray Stell wrote: pg_controldata command is helpful. Archiving wal not required, but you can roll it either way. That is my confusion - Archiving wal does not conflict in any way with streaming replication? What if streaming replication lags behind (especially with a lot of connections). I don't know about the any way deal. The admin cookbook says: There are two main ways to set up streaming replication: with or without an additional archive. Set up without an external archive is presented here, as it is both the most simple and efficient way. There is one downside that suggests the simple approach may not be appropriate for larger databases, explained later in the recipe. It looks like that has to do with the initial backup for building the standby taking to long. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] PostgreSQL 9.0 Streaming Replication Configuration
Thank you for letting me know about pg_controldata. I have been playing around
with this tool.
I notice on my master server I have:
Latest checkpoint location: 1E3/F220
Prior checkpoint location:1E3/F120
Latest checkpoint's REDO location:1E3/F220
And on the slave server (where it is archiving to), I have:
Latest checkpoint location: 1E3/EF20
Prior checkpoint location:1E3/EF20
Latest checkpoint's REDO location:1E3/EF20
These are the main differences - should these match or is this a sign of being
too out of sync? How can I best use this tool?
Thank you
Ogden
On Feb 8, 2011, at 8:47 PM, Ray Stell wrote:
pg_controldata command is helpful.
Archiving wal not required, but you can roll it either way.
On Tue, Feb 08, 2011 at 04:46:51PM -0600, Ogden wrote:
Hello all,
I have set up PostgreSQL Streaming Replication and all seems to work fine
when updating records as the records are instantaneously updated on the
slave, however, I was wondering perhaps if someone can give me some
verification that what I am doing is alright or some more insight into what
I am doing. Perhaps this will also help others in the future.
First on the master, I have the following in /var/lib/pgsql/data/standby.sh:
#!/bin/sh
LOG_FILE=/tmp/postgres_wal_archiving.log
log() { echo `date --rfc-3339=ns` $1 $LOG_FILE; }
log_error() { echo `date --rfc-3339=ns` $1 $LOG_FILE; exit 1; }
wal_path=$1
wal_file=$2
backup_server=slave01
remote_archive=/var/lib/pgsql/walfiles/$wal_file
log Transfering file to backup server, filename: $wal_file
rsync $wal_path $backup_server:$remote_archive
if [ $? -eq 0 ]; then
log Transfer to slave server completed
else
log_error Sending $wal_file failed.
fi
On the slave, I create the directory /var/lib/pgsql/walfiles
(remote_archive) for the script to copy the walfiles over to.
Then, within the master's postgresql.conf I have:
wal_level = hot_standby
archive_mode = on
archive_command = '/var/lib/pgsql/data/standby.sh %p %f /dev/null'#
The same script as above
archive_timeout = 30
max_wal_senders = 5
wal_keep_segments = 32
#hot_standby = off
I start up the master server and verify that files are indeed being SCPed
over to /var/lib/pgsql/walfiles (also processes shows: 'archiver process
last was 00010003001E').
After starting up on the master, I rsync over the data/ directory to the
slave:
/path/to/psql -c SELECT pg_start_backup('label', true)
rsync -avz --delete /var/lib/pgsql/data/ slave01:/var/lib/pgsql/data
--exclude postmaster.pid
/path/to/psql -c SELECT pg_stop_backup()
And I add recovery.conf over on the the slave's data/ directory:
standby_mode = 'on'
primary_conninfo = 'host=master_ip port=5432 user=postgres'
trigger_file = '/tmp/trigger'
restore_command='cp /var/lib/pgsql/walfiles/%f %p'
And in the slave's postgresql.conf, I remove the comment on :
hot_standby = on
Upon starting the slave, everything works fine and updates to records occur
on the slave immediately (what is the actual timing for this)?
My confusion is: does streaming replication require WAL archiving as I have
illustrated above or is it a just in case scenario? Also, the
restore_command on the slave - is this correct, assuming that the master is
dropping off files via SCP to /var/lib/pgsql/walfiles ?
Thank you very much
Ogden Nefix
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] PostgreSQL 9.0 service error : The service did not respond to the start or control request in a timely fashion.
Yesterday, my postgresql 9.0 service run well with user postgres. But today when it start, it have error The service did not respond to the start or control request in a timely fashion. When I change my user start service to Local System Account and check Allow service to interact with desktop, postgresql service start well. I have install dotNet framework 3.5 SP1 (include dotNet framework 1 Sp 1) on windows 2003 How to fix error. Thanks in advance Tuan Hoang Anh
Re: [GENERAL] PostgreSQL 9.0 RPMs for RHEL 6 and Fedora 14 released
On Mon, 2010-12-06 at 09:18 +0300, Allan Kamau wrote: [r...@fc12-macbookpro ~]# yum -y install pgadmin3; Package is there: http://yum.pgrpms.org/9.0/fedora/fedora-12-x86_64/repoview/pgadmin3_90.html Please run yum install pgadmin3_90 You may need to remove the old one before that. 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: [GENERAL] PostgreSQL 9.0 RPMs for RHEL 6 and Fedora 14 released
2010/12/3 Devrim GÜNDÜZ dev...@gunduz.org: On Sun, 2010-11-21 at 12:39 +0300, Allan Kamau wrote: I am unable to obtain (using yum) a version of pgAdmin3 that can connect fruitfully to postgreSQL 9.x. My installation reports that the version I do have 1.10.5 is the latest. Should be fixed as of yesterday. 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 Dear Devrim, It seems that I am unable to perform a successful upgrade, please have a look at the commands and outputs below. [r...@fc12-macbookpro ~]# rpm -ivh http://yum.pgrpms.org/reporpms/9.0/pgdg-fedora-9.0-2.noarch.rpm; Retrieving http://yum.pgrpms.org/reporpms/9.0/pgdg-fedora-9.0-2.noarch.rpm Preparing...### [100%] package pgdg-fedora-9.0-2.noarch is already installed [r...@fc12-macbookpro ~]# yum -y install pgadmin3; . . . . Setting up Install Process Package pgadmin3-1.10.5-1.fc12.x86_64 already installed and latest version Nothing to do You have new mail in /var/spool/mail/root [r...@fc12-macbookpro ~]# -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] PostgreSQL 9.0 RPMs for RHEL 6 and Fedora 14 released
On Sun, 2010-11-21 at 12:39 +0300, Allan Kamau wrote: I am unable to obtain (using yum) a version of pgAdmin3 that can connect fruitfully to postgreSQL 9.x. My installation reports that the version I do have 1.10.5 is the latest. Should be fixed as of yesterday. 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: [GENERAL] PostgreSQL 9.0 RPMs for RHEL 6 and Fedora 14 released
2010/11/14 Devrim GÜNDÜZ dev...@gunduz.org: I just released PostgreSQL 9.0 RPM for Red Hat Enterprise Linux 6 and Fedora 14, on both x86 and x86_64. Please note that 9.0 packages have a different layout as compared to previous ones. You may want to read this blog post about this first: http://people.planetpostgresql.org/devrim/index.php?/archives/48-What-is-new-in-PostgreSQL-9.0-RPMs.html Installing PostgreSQL 9.0 on these platforms are quite easy. First, install repository RPM from here: http://yum.pgrpms.org/reporpms/repoview/letter_p.group.html Then, yum groupinstall PostgreSQL Database Server PGDG will install minimum package sets for you. Here are all packages that have been released so far: RHEL 6: http://yum.pgrpms.org/9.0/redhat/rhel-6-i386/repoview/ http://yum.pgrpms.org/9.0/redhat/rhel-6-x86_64/repoview/ Fedora 14: http://yum.pgrpms.org/9.0/fedora/fedora-14-i386/repoview/ http://yum.pgrpms.org/9.0/fedora/fedora-14-x86_64/repoview/ If you find any issues with the repository or packaging, please send an e-mail to me. 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 I am unable to obtain (using yum) a version of pgAdmin3 that can connect fruitfully to postgreSQL 9.x. My installation reports that the version I do have 1.10.5 is the latest. I am running FC12 64bit and I have installed the latest repository as advised here http://yum.pgrpms.org/reporpms/repoview/letter_p.group.html; but it seems it only provides me with pgadmin3 1.10.5 as shown below. Package pgadmin3-1.10.5-1.fc12.x86_64 already installed and latest version Allan. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] PostgreSQL 9.0 RPMs for RHEL 6 and Fedora 14 released
I just released PostgreSQL 9.0 RPM for Red Hat Enterprise Linux 6 and Fedora 14, on both x86 and x86_64. Please note that 9.0 packages have a different layout as compared to previous ones. You may want to read this blog post about this first: http://people.planetpostgresql.org/devrim/index.php?/archives/48-What-is-new-in-PostgreSQL-9.0-RPMs.html Installing PostgreSQL 9.0 on these platforms are quite easy. First, install repository RPM from here: http://yum.pgrpms.org/reporpms/repoview/letter_p.group.html Then, yum groupinstall PostgreSQL Database Server PGDG will install minimum package sets for you. Here are all packages that have been released so far: RHEL 6: http://yum.pgrpms.org/9.0/redhat/rhel-6-i386/repoview/ http://yum.pgrpms.org/9.0/redhat/rhel-6-x86_64/repoview/ Fedora 14: http://yum.pgrpms.org/9.0/fedora/fedora-14-i386/repoview/ http://yum.pgrpms.org/9.0/fedora/fedora-14-x86_64/repoview/ If you find any issues with the repository or packaging, please send an e-mail to me. 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: [GENERAL] PostgreSQL 9.0 (x86-64) and Windows 7 (x86-64) - Unable to install
Although I have not yet received any feedback from the BitRock support, I have meanwhile done some further tests. Most important result is that the installer finished flawlessly after I changed the TEMP and TMP variables back to the default %USERPROFILE%\AppData\Local\Temp. I am interested to hear how the installer is intended to handle links under Windows, because a link might also be contained within a non-default installation path. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] PostgreSQL 9.0 (x86-64) and Windows 7 (x86-64) - Unable to install
On Thu, Oct 7, 2010 at 9:43 AM, Dr. Peter Voigt pvo...@uos.de wrote: Although I have not yet received any feedback from the BitRock support, I closed the ticket with them - we know what the problem was in your case, and we have enough info to try to put some additional checks in the installer to prevent it biting people in future releases (or at least give a more useful error message). I have meanwhile done some further tests. Most important result is that the installer finished flawlessly after I changed the TEMP and TMP variables back to the default %USERPROFILE%\AppData\Local\Temp. Thats good to hear. I am interested to hear how the installer is intended to handle links under Windows, because a link might also be contained within a non-default installation path. It does handle the links OK, it's just that those particular ones have an unusual ACL on them which caused our pre-installation actions to go haywire. If such a problem occurs with the installation path, you should get a regular permission denied error. Regards, Dave. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] PostgreSQL 9.0 (x86-64) and Windows 7 (x86-64) - Unable to install
For the benefit of the list, I've raised this issue with the people who supply the installer technology, as I can't see any reason why our code would get this wrong. On Thu, Sep 30, 2010 at 9:53 PM, Dr. Peter Voigt pvo...@uos.de wrote: Dave Page dp...@pgadmin.org writes: A couple of questions for you Peter (and thanks for bearing with us while we figure this out): - How are you running the installer? Are you logged in as Administrator, or are you using Run As Administrator or something similar? I am logged in as Administrator when running the installer. - What's the output from the SET command when run in the same user environment as the installer (ie. from an Administrator command prompt, or one launched however you've escalated your privileges). Please find the environment of user Administrator attached: ACR_BIN=C:\Program Files (x86)\Adobe\Reader 9.0\Reader ALLUSERSPROFILE=C:\ProgramData APACHE2_HOME=C:\Program Files\Apache Group\Apache22 APACHESRC=C:\Programme\Apache Group\Apache22 APPDATA=C:\Users\Administrator\AppData\Roaming asl.log=Destination=file;OnFirstLog=command,environment,parent BIBINPUTS=D:\home\pvoigt\tex\texsty BSTINPUTS=D:\home\pvoigt\tex\texsty CATALINA_HOME=C:\Program Files\tomcat60 CLASSPATH=.;C:\Programme\mysql-connector-java-5.1.10\mysql-connector-java-5.1.10-bin.jar;C:\Programme\sqljdbc_1.1_deu\sqljdbc.jar;C:\Program Files\tomcat60\lib\servlet-api.jar;d:\home\pvoigt\java\vog-libs\VogSystem.jar;d:\home\pvoigt\java\vog-libs\VogIO.jar;d:\home\pvoigt\java\vog-libs\MyIO.jar;d:\home\pvoigt\java\vog-libs\VogDbUtil.jar;d:\home\pvoigt\java\vog-libs\VogTime.jar CommonProgramFiles=C:\Program Files\Common Files CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files CommonProgramW6432=C:\Program Files\Common Files COMPUTERNAME=TIGER2008 ComSpec=C:\Windows\system32\cmd.exe CURL_CA_BUNDLE=D:\temp\ca-bundle.crt EASY_INSTALL_BIN=C:\Programme\Python26\Scripts EDITOR=C:\Program Files\vim\vim73\gvim.exe EMACS_OPTS=-geometry 80x45 --reverse-video FOP_HOME=C:\Program Files\fop FP_NO_HOST_CHECK=NO FRD_BIN=D:\local\bin FTPROOT=E:\srv\ftp GNUPGHOME=D:\home\pvoigt\.gnupg GNUWIN32_BIN=D:\local\GnuWin32\bin GSV_BIN=C:\Program Files\ghostgum\gsview GS_BIN=C:\Program Files\gs\gs8.64\bin GS_LIB=C:\Program Files\gs\gs8.64\lib;C:\Program Files\gs\fonts HEISE=D:\home\pvoigt\ct-ix\inhalt.frm HOME=D:\home\pvoigt HOMEDIR=D:\home\pvoigt\.gnupg HOMEDRIVE=C: HOMEPATH=\Users\Administrator INFODIR=D:\local\Emacs\emacs\info;D:\local\Emacs\emacs\site-info INFOPATH=D:\local\Emacs\emacs\info;D:\local\Emacs\emacs\site-info JAVA_HOME=C:\Program Files\Java\jdk KLEOPATRA_LOGDIR=D:\home\pvoigt\.gnupg\kleopatra LANG=DE LESS=-I -N -M -S LOCALAPPDATA=C:\Users\Administrator\AppData\Local LOCAL_BIN=D:\local\bin LOGONSERVER=\\TIGER2008 LYNX_CFG=C:\Program Files (x86)\Lynx\lynx.cfg LYNX_LSS=C:\Program Files (x86)\Lynx\lynx.lss MIKTEX_BIN=D:\local\MiKTeX\miktex\bin MINGW_HOME=D:\local\MinGW MSYS_HOME=D:\local\msys\1.0 MYSQL_JDBC_HOME=C:\Program Files\mysql-connector-java-5.1.10 NUMBER_OF_PROCESSORS=2 OPENSSL=C:\Program Files (x86)\openssl OPENSSL_CONF=D:\home\pvoigt\certs\ca\my_openssl.config OPENSSL_INC=C:\Program Files (x86)\openssl\include OPENSSL_LIB=C:\Program Files (x86)\openssl\lib OS=Windows_NT Os2LibPath=%Os2LibPath% PAGER=D:/local/gnuwin32/bin/less.exe Path=C:\Program Files\Common Files\Microsoft Shared\Windows Live;C:\Program Files (x86)\PC Connectivity Solution\;C:\Program Files\ImageMagick;D:\local\MiKTeX\miktex\bin;c:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\GNU\GnuPG\pub;C:\Program Files (x86)\Common Files\Acronis\SnapAPI\;C:\Program Files (x86)\QuickTime\QTSystem\;C:\Program Files\Common Files\Microsoft Shared\Windows Live;D:\local\tex4ht\bin\win32;D:\local\tex4ht\bin\ht\win32;C:\Program Files (x86)\openssl\bin;C:\Programme\gnutls\bin;d:\local\bin;d:\local\gnuwin32\bin;D:\home\pvoigt\ct-ix;C:\Program Files (x86)\Emacs\emacs\bin;C:\Program Files (x86)\GNU\GnuPG;C:\Program Files\Java\jdk\bin;C:\Program Files\Python27;C:\Program Files\Python27\Scripts;C:\Program Files\vim\vim73;C:\Program Files\perl\bin;C:\Program Files (x86)\lynx;C:\Program Files (x86)\Adobe\Reader 9.0\Reader;C:\Program Files (x86)\php;D:\home\pvoigt\python;C:\Program Files\ghostgum\gsview;C:\Program Files\MySQL\MySQL Server 5.1\bin;C:\Program Files\7-Zip;C:\Programme\Python26\Scripts;C:\Program Files (x86)\wget;C:\Program Files (x86)\curl;C:\Program Files\curl;C:\Program Files\ant\bin;C:\Program Files (x86)\NTP\bin;C:\Program Files (x86)\Mozilla Firefox PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC PROCESSOR_ARCHITECTURE=AMD64 PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 15 Stepping 11, GenuineIntel PROCESSOR_LEVEL=6 PROCESSOR_REVISION=0f0b ProgramData=C:\ProgramData
Re: [GENERAL] PostgreSQL 9.0 (x86-64) and Windows 7 (x86-64) - Unable to install
(This is the second time I send this, as the first message apparently did not make it) Dr. Peter Voigt, 30.09.2010 14:42: If there are no other users out there with comparable problems I could give the ZIP-installer a try under: http://www.enterprisedb.com/products/pgbindownload.do There is a file postgresql-9.0.0-1-windows_x64-binaries.zip. I did not yet try this because I am new to PostgreSQL. It's actually not that hard ;) You first need to create a datadirectory using initdb.exe http://www.postgresql.org/docs/current/static/app-initdb.html Make sure the user account under which the server will be running has full (write) access to that directory. For me it is enough to run initdb -D /path/to/datadir --lc-messages=English -U postgres E UTF8 -A md5 - how to start the database from the command line, Once the data directory has been created, simply use pg_ctl: pg_ctl -D /path/to/datadir start http://www.postgresql.org/docs/current/static/app-pg-ctl.html - how to setup the PostgreSQL service from the command line, pg_ctl -D /path/to/your/datadir register (see the above link to the manual) - what registry entries are required. None. If you can answer the above three questions (each with one sentence), I will immediately start installation and tests, because I hope - from my short but good PostgreSQL 9.0 experiences under Linux - that just the installer fails on my system but not the database system itself. I have put the above statements in some very simple batch files to be able to easily repeat these steps Regards Thomas -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] PostgreSQL 9.0 (x86-64) and Windows 7 (x86-64) - Unable to install
* Dave Page wrote: Thats very odd, but it explains why things are going wrong - essentially, the prerequisites are being unpacked to: C:\Users\Administrator\AppData\Local But the installer expects to find them in: C:\Users\Administrator\Lokale Einstellungen\ Which is a link to the first folder. I (as the guy the wrote the original version of the installer) expect them to be in: C:\Users\Administrator\Lokale Einstellungen\Temp\ So, it sounds like there are two questions for me to figure out - why is the installer not able to follow the link and find the files (which is probably a question for BitRock), and why isn't it using the actual Temp subdirectory as it's supposed to. It can't follow the link because these links (actually, junctions) have ACLs that deny FILE_READ_DATA, which means you cannot enumerate the contents of the target directory through the link. See http://technet.microsoft.com/en-us/magazine/ee851567.aspx for an explanation of the ACLs. The OP indicates in his reply to your message that his %TEMP% path is C:\Users\ADMINI~1\LOKALE~1\Temp , which is using one of these junctions. This is definitely not the default value set when the Administrator profile is created during installation; that value would be C:\Users\Administrator\AppData\Local\Temp . I would recommend to change the user environment variables (TEMP and TMP) to the correct value and retry. Of course, even if it works, this does not answer two questions: 1. How did TEMP end up with this value? 2. Why does the installer use the wrong directory? There are two things I can think of with regard to 1. The more likely one is that there is some logon script or group policy that applies to the local Administrator account, which was written for XP clients and therefore uses XP paths. The other idea is that his system may have been upgraded from XP by way of Vista and somehow kept the old paths intact. As for 2, I suspect that somewhere in the installer, it walks down the path to the TEMP directory, and fails at the junction because it cannot read the contents of its target directory. -- Christian -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] PostgreSQL 9.0 (x86-64) and Windows 7 (x86-64) - Unable to install
On Fri, Oct 1, 2010 at 11:01 AM, Christian Ullrich ch...@chrullrich.net wrote: * Dave Page wrote: So, it sounds like there are two questions for me to figure out - why is the installer not able to follow the link and find the files (which is probably a question for BitRock), and why isn't it using the actual Temp subdirectory as it's supposed to. It can't follow the link because these links (actually, junctions) have ACLs that deny FILE_READ_DATA, which means you cannot enumerate the contents of the target directory through the link. See http://technet.microsoft.com/en-us/magazine/ee851567.aspx for an explanation of the ACLs. Interesting, thanks for the link. The OP indicates in his reply to your message that his %TEMP% path is C:\Users\ADMINI~1\LOKALE~1\Temp , which is using one of these junctions. This is definitely not the default value set when the Administrator profile is created during installation; that value would be C:\Users\Administrator\AppData\Local\Temp . I would recommend to change the user environment variables (TEMP and TMP) to the correct value and retry. Agreed. Of course, even if it works, this does not answer two questions: 1. How did TEMP end up with this value? 2. Why does the installer use the wrong directory? There are two things I can think of with regard to 1. The more likely one is that there is some logon script or group policy that applies to the local Administrator account, which was written for XP clients and therefore uses XP paths. The other idea is that his system may have been upgraded from XP by way of Vista and somehow kept the old paths intact. I would lean towards the former - the upgrade issue seems like something Microsoft would have ensured works correctly, though it's possible that a pre-upgrade installation might be in an unexpected state. As for 2, I suspect that somewhere in the installer, it walks down the path to the TEMP directory, and fails at the junction because it cannot read the contents of its target directory. I've asked BitRock to confirm or deny that. I'm thinking we should add a pre-installation check to ensure we can write to $TEMP, and execute what we've written. Will look into that... -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] PostgreSQL 9.0 (x86-64) and Windows 7 (x86-64) - Unable to install
On Fri, Oct 1, 2010 at 1:06 PM, Craig Ringer cr...@postnewspapers.com.au wrote: On 10/01/2010 06:30 PM, Dave Page wrote: As for 2, I suspect that somewhere in the installer, it walks down the path to the TEMP directory, and fails at the junction because it cannot read the contents of its target directory. I've asked BitRock to confirm or deny that. It should be pretty trivial to test with Process Monitor. As I don't think my (English) system will have that junction point, I'm not sure I can observe the results with junction points, but I can certainly see if the installer is trying to walk the path. [clickety click] Yes, the installer walks the path. For each directory it does: FASTIO_NETWORK_QUERY_OPEN (QueryOpen) FASTIO_QUERY_INFORMATION (QueryOpenNetworkInformation) IRP_MJ_DIRECTORY_CONTROL (QueryDirectory) (see the attached screenshot) IRP_MJ_DIRECTORY_CONTROL is documented in MSDN as: http://msdn.microsoft.com/en-us/library/ff548658(VS.85).aspx The rest, I have no idea about. I don't do Windows innards by choice. You would think it would walk backwards in the event of an error rather than the other way round. Anyway, BitRock should be able to tell us, unless it's their underlying toolkit/language/SDK that's doing it. I wonder why it's walking the path? Such things are rarely a good idea, unless you're trying to backtrack on an access denied error to find out at what level of a path you lost access. Right :-) I really should read to the end before commenting. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] PostgreSQL 9.0 (x86-64) and Windows 7 (x86-64) - Unable to install
First of all: Thanks to all who contributed to this issue. There are many helpful and interesting comments. I am going to reply to Christian's first question: How did TEMP end up with this value? I have just scanned my installation protocol which says, that I made a registry backup of the current user enviroment right after the basic system installation. After that backup I restored the previously saved Windows XP Pro x86 DE user environment. This step changed the TEMP setting from its default value to C:\Users\ADMINI~1\LOKALE~1\Temp (8.3 notation), which corresponds to C:\Users\Administrator\Lokale Einstellungen\Temp. I unintentionally changed the TEMP variable from its default setting. I should have checked whether the TEMP values has changed or not - but I did not. Newertheless, I would not have expected any problems from a changed TEMP setting even if it contains links. From my backup of the original user environment [HKEY_CURRENT_USER\Environment] I can reconstruct the default value of TEMP: TEMP=%USERPROFILE%\AppData\Local\Temp which resolves to TEMP=C:\Users\Administrator\AppData\Local\Temp The default TEMP setting does not contain any links. As a link is obviously causing the installer to fail, it will probably finish without problems when using either the default TEMP setting or any non-default setting that does not contain any links. Before I am going to install with the default TEMP setting I am doing the desired tests for the BitRock Support and wait for the answer. I will keep the list informed about any new results. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] PostgreSQL 9.0 (x86-64) and Windows 7 (x86-64) - Unable to install
Hi Peter, We tried to reproduce this issue but could not do so. We have tried both the cases but both were not reproducible. Can you please provide more information which can help us in reproducing the issue, Thanks, Dharmendra From: Dr. Peter Voigt pvo...@uos.de Date: Tue, Sep 28, 2010 at 11:53 PM Subject: [GENERAL] PostgreSQL 9.0 (x86-64) and Windows 7 (x86-64) - Unable to install To: pgsql-general@postgresql.org I cannot install PostgreSQL 9.0 (x86-64) under Windows 7 (x86-64). The installer fails right after starting the installation process with the message: An error occurred executing the Microsoft VC++ runtime installer. I am using the installer from EnterpriseDB http://www.enterprisedb.com/products/pgdownload.do. Installation file is postgresql-9.0.0-1-windows_x64.exe. Unfortunately there is no %TEMP%\install-postgresql.log. When scanning the mailing lists under http://www.postgresql.org/community/lists/ and under http://forums.enterprisedb.com/forums/show/9.page I can see that this error has been described for several times with PostgreSQL 8.3 and 8.4 under different Windows variants. A common hint was to activate the Windos Scripting Host (WSH) allthough it obviously does not help in all cases. On my machine the WSH is activated and working. Under http://www.enterprisedb.com/learning/pginst_guide.do#troubleshooting you can read about the command line options of the EnterpriseDB PostgreSQL Installer. An attempt with --install_runtimes 0 fails again but with the different error message: Unknown error while running C:\Users\Administrator\Lokale Einstellungen\postgres_installer\getlocales.exe Again there is no %TEMP%\install-postgresql.log. As the second message is suggesting I am working as local Administrator while installing PostgreSQL. Maybe it is worth to be mentioned that I have installed Microsoft Visual Studio 2008 Pro DE. Therefore the installation of the VC++ runtime should not be neccessary. I am using now MySQL for serveral years and would like to compare it with a current PostgreSQL version. The installation of PostgreSQL under Windows is really disappointing but the same worked without problems under Linux x86-64 (openSUSE 11.0). Under Linux I have used the EnterpriseDB Installer of PostgreSQL 9.0 (x86-64) as well. The installation file is postgresql-9.0.0-1-linux-x64.bin. Is this problem already known and is there a solution for it? -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general -- Dharmendra Goyal Senior Software Engineer EnterpriseDB Corporation The Enterprise Postgres Company Phone: +91-20-30589493 Mobile: +91-9552103323 Website: http://www.enterprisedb.com EnterpriseDB Blog: http://blogs.enterprisedb.com/ Follow us on Twitter: http://www.twitter.com/enterprisedb This e-mail message (and any attachment) is intended for the use of the individual or entity to whom it is addressed. This message contains information from EnterpriseDB Corporation that may be privileged, confidential, or exempt from disclosure under applicable law. If you are not the intended recipient or authorized to receive this for the intended recipient, any use, dissemination, distribution, retention, archiving, or copying of this communication is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately by reply e-mail and delete this message.
Re: [GENERAL] PostgreSQL 9.0 (x86-64) and Windows 7 (x86-64) - Unable to install
Hi Dharmendra, thanks for your reply. This kind of errors, which cannot be reproduced on other machines are bad and leave no chance for developers to solve them. Unfortunately the installer does not leave any log files. The Windows event log has no entries about the installation attempt as well. I do not know what further information could be helpful. My first idea was that my installed MS Visual Studio 2008 could be the problem. Therefore I tried the --install_runtimes 0 option - unfortunately with no success. My Visual Studio installation works as expected. I conclude it from various projects which all built fine. I am running a Windows 7 x86-64 for about 3 months and it runs without problems. I cleanly installed the system onto an empty, e.g. formated harddrive. As the first described error An error occurred executing the Microsoft VC++ runtime installer has been discussed with previous releases of PostgreSQL, e.g. http://forums.enterprisedb.com/posts/list/2328.page I think that it is a known issue. Moreover, exactly the same error has been described in the EnterpriseDB forum under http://forums.enterprisedb.com/posts/list/2303.page with PostgreSQL 9.0 and Windows 7 x86-64. However, both posts remain un-replied until today. If there are no other users out there with comparable problems I could give the ZIP-installer a try under: http://www.enterprisedb.com/products/pgbindownload.do There is a file postgresql-9.0.0-1-windows_x64-binaries.zip. I did not yet try this because I am new to PostgreSQL. I first have to figure - how to start the database from the command line, - how to setup the PostgreSQL service from the command line, - what registry entries are required. If you can answer the above three questions (each with one sentence), I will immediately start installation and tests, because I hope - from my short but good PostgreSQL 9.0 experiences under Linux - that just the installer fails on my system but not the database system itself. If you need any other information that might help, please let me know. I would really like to get some more knowledge about PostgreSQL. Regards, Peter -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] PostgreSQL 9.0 (x86-64) and Windows 7 (x86-64) - Unable to install
On Thu, Sep 30, 2010 at 1:42 PM, Dr. Peter Voigt pvo...@uos.de wrote: Hi Dharmendra, thanks for your reply. This kind of errors, which cannot be reproduced on other machines are bad and leave no chance for developers to solve them. Unfortunately the installer does not leave any log files. Please look for any logfiles in %TEMP% starting with bitrock. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] PostgreSQL 9.0 (x86-64) and Windows 7 (x86-64) - Unable to install
Dave Page dp...@pgadmin.org writes: On Thu, Sep 30, 2010 at 1:42 PM, Dr. Peter Voigt pvo...@uos.de wrote: Hi Dharmendra, thanks for your reply. This kind of errors, which cannot be reproduced on other machines are bad and leave no chance for developers to solve them. Unfortunately the installer does not leave any log files. Please look for any logfiles in %TEMP% starting with bitrock. Well, the installer does not leave any file starting with bitrock in my %TEMP% directory. I am using the default %TEMP% value as created during system installation. Its value is (German operating system) C:\Users\Administrator\Lokale Einstellungen\Temp or in 8.3 notation C:\Users\ADMINI~1\LOKALE~1\Temp. The subdir Lokale Einstellungen is a link to C:\Users\Administrator\AppData\Local: administra...@tiger2008:C:\Users\Administrator dir /a |grep -i lokale 28.08.2010 15:22VERBINDUNG Lokale Einstellungen [C:\Users\Administrator \AppData\Local] However, a scan of my whole system partition reveales a file bitrock.log under C:\Users\Administrator\AppData\Local. I have just re-created it with a fresh installation attempt. Please find it attached. I have tried to interpret the error in the log. The installer complains about not finding file C:\Users\Administrator\Lokale Einstellungen\postgresql_installer\installruntimes.vbs. I suppose it is important for you to know that this file installruntimes.vbs is present - but under C:\Users\Administrator\AppData\Local. This is the same directory where I finally found the log. Log started 09/30/10 at 19:42:57 Preferred installation mode : qt Trying to init installer in mode qt Mode qt successfully initialized Could not find registry key HKEY_LOCAL_MACHINE\SOFTWARE\PostgreSQL\Installations\postgresql-x64-9.0 Data Directory. Setting variable iDataDirectory to empty value Could not find registry key HKEY_LOCAL_MACHINE\SOFTWARE\PostgreSQL\Installations\postgresql-x64-9.0 Base Directory. Setting variable iBaseDirectory to empty value Could not find registry key HKEY_LOCAL_MACHINE\SOFTWARE\PostgreSQL\Installations\postgresql-x64-9.0 Service ID. Setting variable iServiceName to empty value Could not find registry key HKEY_LOCAL_MACHINE\SOFTWARE\PostgreSQL\Installations\postgresql-x64-9.0 Service Account. Setting variable iServiceAccount to empty value Could not find registry key HKEY_LOCAL_MACHINE\SOFTWARE\PostgreSQL\Installations\postgresql-x64-9.0 Super User. Setting variable iSuperuser to empty value Could not find registry key HKEY_LOCAL_MACHINE\SOFTWARE\PostgreSQL\Installations\postgresql-x64-9.0 Branding. Setting variable iBranding to empty value Could not find registry key HKEY_LOCAL_MACHINE\SOFTWARE\PostgreSQL\Installations\postgresql-x64-9.0 Version. Setting variable brandingVer to empty value Could not find registry key HKEY_LOCAL_MACHINE\SOFTWARE\PostgreSQL\Installations\postgresql-x64-9.0 Shortcuts. Setting variable iShortcut to empty value Could not find registry key HKEY_LOCAL_MACHINE\SOFTWARE\PostgreSQL\Installations\postgresql-x64-9.0 DisableStackBuilder. Setting variable iDisableStackBuilder to empty value [19:43:01] Existing base directory: [19:43:01] Existing data directory: [19:43:01] Using branding: PostgreSQL 9.0 [19:43:01] Using Super User: postgres and Service Account: postgres [19:43:01] Using Service Name: postgresql-x64-9.0 Executing cscript //NoLogo "C:\Users\Administrator\Lokale Einstellungen\postgresql_installer\installruntimes.vbs" "C:\Users\Administrator\Lokale Einstellungen\postgresql_installer\vcredist_x64.exe" Script exit code: 1 Script output: Eingabefehler: Die Skriptdatei "C:\Users\Administrator\Lokale Einstellungen\postgresql_installer\installruntimes.vbs" wurde nicht gefunden. Script stderr: Program ended with an error exit code Error running cscript //NoLogo "C:\Users\Administrator\Lokale Einstellungen\postgresql_installer\installruntimes.vbs" "C:\Users\Administrator\Lokale Einstellungen\postgresql_installer\vcredist_x64.exe" : Program ended with an error exit code -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] PostgreSQL 9.0 (x86-64) and Windows 7 (x86-64) - Unable to install
On Thu, Sep 30, 2010 at 7:41 PM, Dr. Peter Voigt pvo...@uos.de wrote: Dave Page dp...@pgadmin.org writes: On Thu, Sep 30, 2010 at 1:42 PM, Dr. Peter Voigt pvo...@uos.de wrote: Hi Dharmendra, thanks for your reply. This kind of errors, which cannot be reproduced on other machines are bad and leave no chance for developers to solve them. Unfortunately the installer does not leave any log files. Please look for any logfiles in %TEMP% starting with bitrock. Well, the installer does not leave any file starting with bitrock in my %TEMP% directory. I am using the default %TEMP% value as created during system installation. Its value is (German operating system) C:\Users\Administrator\Lokale Einstellungen\Temp or in 8.3 notation C:\Users\ADMINI~1\LOKALE~1\Temp. The subdir Lokale Einstellungen is a link to C:\Users\Administrator\AppData\Local: administra...@tiger2008:C:\Users\Administrator dir /a |grep -i lokale 28.08.2010 15:22 VERBINDUNG Lokale Einstellungen [C:\Users\Administrator \AppData\Local] However, a scan of my whole system partition reveales a file bitrock.log under C:\Users\Administrator\AppData\Local. I have just re-created it with a fresh installation attempt. Please find it attached. I have tried to interpret the error in the log. The installer complains about not finding file C:\Users\Administrator\Lokale Einstellungen\postgresql_installer\installruntimes.vbs. I suppose it is important for you to know that this file installruntimes.vbs is present - but under C:\Users\Administrator\AppData\Local. This is the same directory where I finally found the log. Thats very odd, but it explains why things are going wrong - essentially, the prerequisites are being unpacked to: C:\Users\Administrator\AppData\Local But the installer expects to find them in: C:\Users\Administrator\Lokale Einstellungen\ Which is a link to the first folder. I (as the guy the wrote the original version of the installer) expect them to be in: C:\Users\Administrator\Lokale Einstellungen\Temp\ So, it sounds like there are two questions for me to figure out - why is the installer not able to follow the link and find the files (which is probably a question for BitRock), and why isn't it using the actual Temp subdirectory as it's supposed to. A couple of questions for you Peter (and thanks for bearing with us while we figure this out): - How are you running the installer? Are you logged in as Administrator, or are you using Run As Administrator or something similar? - What's the output from the SET command when run in the same user environment as the installer (ie. from an Administrator command prompt, or one launched however you've escalated your privileges). -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] PostgreSQL 9.0 (x86-64) and Windows 7 (x86-64) - Unable to install
Dave Page dp...@pgadmin.org writes: A couple of questions for you Peter (and thanks for bearing with us while we figure this out): - How are you running the installer? Are you logged in as Administrator, or are you using Run As Administrator or something similar? I am logged in as Administrator when running the installer. - What's the output from the SET command when run in the same user environment as the installer (ie. from an Administrator command prompt, or one launched however you've escalated your privileges). Please find the environment of user Administrator attached: ACR_BIN=C:\Program Files (x86)\Adobe\Reader 9.0\Reader ALLUSERSPROFILE=C:\ProgramData APACHE2_HOME=C:\Program Files\Apache Group\Apache22 APACHESRC=C:\Programme\Apache Group\Apache22 APPDATA=C:\Users\Administrator\AppData\Roaming asl.log=Destination=file;OnFirstLog=command,environment,parent BIBINPUTS=D:\home\pvoigt\tex\texsty BSTINPUTS=D:\home\pvoigt\tex\texsty CATALINA_HOME=C:\Program Files\tomcat60 CLASSPATH=.;C:\Programme\mysql-connector-java-5.1.10\mysql-connector-java-5.1.10-bin.jar;C:\Programme\sqljdbc_1.1_deu\sqljdbc.jar;C:\Program Files\tomcat60\lib\servlet-api.jar;d:\home\pvoigt\java\vog-libs\VogSystem.jar;d:\home\pvoigt\java\vog-libs\VogIO.jar;d:\home\pvoigt\java\vog-libs\MyIO.jar;d:\home\pvoigt\java\vog-libs\VogDbUtil.jar;d:\home\pvoigt\java\vog-libs\VogTime.jar CommonProgramFiles=C:\Program Files\Common Files CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files CommonProgramW6432=C:\Program Files\Common Files COMPUTERNAME=TIGER2008 ComSpec=C:\Windows\system32\cmd.exe CURL_CA_BUNDLE=D:\temp\ca-bundle.crt EASY_INSTALL_BIN=C:\Programme\Python26\Scripts EDITOR=C:\Program Files\vim\vim73\gvim.exe EMACS_OPTS=-geometry 80x45 --reverse-video FOP_HOME=C:\Program Files\fop FP_NO_HOST_CHECK=NO FRD_BIN=D:\local\bin FTPROOT=E:\srv\ftp GNUPGHOME=D:\home\pvoigt\.gnupg GNUWIN32_BIN=D:\local\GnuWin32\bin GSV_BIN=C:\Program Files\ghostgum\gsview GS_BIN=C:\Program Files\gs\gs8.64\bin GS_LIB=C:\Program Files\gs\gs8.64\lib;C:\Program Files\gs\fonts HEISE=D:\home\pvoigt\ct-ix\inhalt.frm HOME=D:\home\pvoigt HOMEDIR=D:\home\pvoigt\.gnupg HOMEDRIVE=C: HOMEPATH=\Users\Administrator INFODIR=D:\local\Emacs\emacs\info;D:\local\Emacs\emacs\site-info INFOPATH=D:\local\Emacs\emacs\info;D:\local\Emacs\emacs\site-info JAVA_HOME=C:\Program Files\Java\jdk KLEOPATRA_LOGDIR=D:\home\pvoigt\.gnupg\kleopatra LANG=DE LESS=-I -N -M -S LOCALAPPDATA=C:\Users\Administrator\AppData\Local LOCAL_BIN=D:\local\bin LOGONSERVER=\\TIGER2008 LYNX_CFG=C:\Program Files (x86)\Lynx\lynx.cfg LYNX_LSS=C:\Program Files (x86)\Lynx\lynx.lss MIKTEX_BIN=D:\local\MiKTeX\miktex\bin MINGW_HOME=D:\local\MinGW MSYS_HOME=D:\local\msys\1.0 MYSQL_JDBC_HOME=C:\Program Files\mysql-connector-java-5.1.10 NUMBER_OF_PROCESSORS=2 OPENSSL=C:\Program Files (x86)\openssl OPENSSL_CONF=D:\home\pvoigt\certs\ca\my_openssl.config OPENSSL_INC=C:\Program Files (x86)\openssl\include OPENSSL_LIB=C:\Program Files (x86)\openssl\lib OS=Windows_NT Os2LibPath=%Os2LibPath% PAGER=D:/local/gnuwin32/bin/less.exe Path=C:\Program Files\Common Files\Microsoft Shared\Windows Live;C:\Program Files (x86)\PC Connectivity Solution\;C:\Program Files\ImageMagick;D:\local\MiKTeX\miktex\bin;c:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\GNU\GnuPG\pub;C:\Program Files (x86)\Common Files\Acronis\SnapAPI\;C:\Program Files (x86)\QuickTime\QTSystem\;C:\Program Files\Common Files\Microsoft Shared\Windows Live;D:\local\tex4ht\bin\win32;D:\local\tex4ht\bin\ht\win32;C:\Program Files (x86)\openssl\bin;C:\Programme\gnutls\bin;d:\local\bin;d:\local\gnuwin32\bin;D:\home\pvoigt\ct-ix;C:\Program Files (x86)\Emacs\emacs\bin;C:\Program Files (x86)\GNU\GnuPG;C:\Program Files\Java\jdk\bin;C:\Program Files\Python27;C:\Program Files\Python27\Scripts;C:\Program Files\vim\vim73;C:\Program Files\perl\bin;C:\Program Files (x86)\lynx;C:\Program Files (x86)\Adobe\Reader 9.0\Reader;C:\Program Files (x86)\php;D:\home\pvoigt\python;C:\Program Files\ghostgum\gsview;C:\Program Files\MySQL\MySQL Server 5.1\bin;C:\Program Files\7-Zip;C:\Programme\Python26\Scripts;C:\Program Files (x86)\wget;C:\Program Files (x86)\curl;C:\Program Files\curl;C:\Program Files\ant\bin;C:\Program Files (x86)\NTP\bin;C:\Program Files (x86)\Mozilla Firefox PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC PROCESSOR_ARCHITECTURE=AMD64 PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 15 Stepping 11, GenuineIntel PROCESSOR_LEVEL=6 PROCESSOR_REVISION=0f0b ProgramData=C:\ProgramData ProgramFiles=C:\Program Files ProgramFiles(x86)=C:\Program Files (x86) ProgramW6432=C:\Program Files prompt=administra...@tiger2008:$p$g PSModulePath=C:\Windows\system32\WindowsPowerShell\v1.0\Modules\ PUBLIC=C:\Users\Public PYTHONPATH=D:\home\pvoigt\python PYTHONSRC=C:\Program Files\Python26 PYTHONSTARTUP=D:\home\pvoigt\python_startup.py
[GENERAL] PostgreSQL 9.0 (x86-64) and Windows 7 (x86-64) - Unable to install
I cannot install PostgreSQL 9.0 (x86-64) under Windows 7 (x86-64). The installer fails right after starting the installation process with the message: An error occurred executing the Microsoft VC++ runtime installer. I am using the installer from EnterpriseDB http://www.enterprisedb.com/products/pgdownload.do. Installation file is postgresql-9.0.0-1-windows_x64.exe. Unfortunately there is no %TEMP%\install-postgresql.log. When scanning the mailing lists under http://www.postgresql.org/community/lists/ and under http://forums.enterprisedb.com/forums/show/9.page I can see that this error has been described for several times with PostgreSQL 8.3 and 8.4 under different Windows variants. A common hint was to activate the Windos Scripting Host (WSH) allthough it obviously does not help in all cases. On my machine the WSH is activated and working. Under http://www.enterprisedb.com/learning/pginst_guide.do#troubleshooting you can read about the command line options of the EnterpriseDB PostgreSQL Installer. An attempt with --install_runtimes 0 fails again but with the different error message: Unknown error while running C:\Users\Administrator\Lokale Einstellungen\postgres_installer\getlocales.exe Again there is no %TEMP%\install-postgresql.log. As the second message is suggesting I am working as local Administrator while installing PostgreSQL. Maybe it is worth to be mentioned that I have installed Microsoft Visual Studio 2008 Pro DE. Therefore the installation of the VC++ runtime should not be neccessary. I am using now MySQL for serveral years and would like to compare it with a current PostgreSQL version. The installation of PostgreSQL under Windows is really disappointing but the same worked without problems under Linux x86-64 (openSUSE 11.0). Under Linux I have used the EnterpriseDB Installer of PostgreSQL 9.0 (x86-64) as well. The installation file is postgresql-9.0.0-1-linux-x64.bin. Is this problem already known and is there a solution for it? -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Postgresql 9.0 and desktop heap and Windows
On Mon, Sep 27, 2010 at 01:29, Heine Ferreira heine.ferre...@gmail.com wrote: Hi Does Postgresql 9.0 still have the problem with the desktop heap on windows? I know you can extend the desktop heap on windows but Microsoft says on their web site you musn't extend it beyond 20K. That allows for about 300 connections on a windows server. I see there is now also a 64 bit windows version. Does Postgresql 9.0 still run on Windows 2000 Server? Yes, I believe it should. However, do remember that Microsoft no longer have even extended support for Windows 2000. On which 64 bit versions of Windows can it run? Any x64 version should work fine. No support for Itanium if you happen to have one of those old versions. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Postgresql 9.0 and desktop heap and Windows
Hi Does Postgresql 9.0 still have the problem with the desktop heap on windows? I know you can extend the desktop heap on windows but Microsoft says on their web site you musn't extend it beyond 20K. That allows for about 300 connections on a windows server. I see there is now also a 64 bit windows version. Does Postgresql 9.0 still run on Windows 2000 Server? On which 64 bit versions of Windows can it run? Thanks H.F.
[GENERAL] PostgreSQL 9.0 beta 3 release announcement
Could someone clarify the info in this paragraph: Note that, due to a system catalog change, an initdb and database reload will be required for upgrading from 9.0Beta1. We encourage users to use this opportunity to test pg_upgrade for the upgrade from Beta2 or an earlier version of 9.0. Please report your results. This suggests that the system catalog change only occurred in Beta2, not Beta3. So if that's the case, why would I want to test pg_upgrade going from Beta2 to Beta3 if they use the same system catalog layout? Thom -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] PostgreSQL 9.0 beta 3 release announcement
Thom Brown wrote: Could someone clarify the info in this paragraph: Note that, due to a system catalog change, an initdb and database reload will be required for upgrading from 9.0Beta1. We encourage users to use this opportunity to test pg_upgrade for the upgrade from Beta2 or an earlier version of 9.0. Please report your results. This suggests that the system catalog change only occurred in Beta2, not Beta3. So if that's the case, why would I want to test pg_upgrade going from Beta2 to Beta3 if they use the same system catalog layout? Yes, this is wrong. It should be We encourage users to use this opportunity to test pg_upgrade for the upgrade from Beta1 or an earlier version of 9.0. Please report your results. However, I see the beta3 release notes are now on the web site so it seems too late to fix this. Sorry I missed seeing this problem earlier. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. + -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] PostgreSQL 9.0 beta 3 release announcement
Bruce Momjian wrote on 12.07.2010 21:34: Thom Brown wrote: Could someone clarify the info in this paragraph: Note that, due to a system catalog change, an initdb and database reload will be required for upgrading from 9.0Beta1. We encourage users to use this opportunity to test pg_upgrade for the upgrade from Beta2 or an earlier version of 9.0. Please report your results. This suggests that the system catalog change only occurred in Beta2, not Beta3. So if that's the case, why would I want to test pg_upgrade going from Beta2 to Beta3 if they use the same system catalog layout? Yes, this is wrong. It should be We encourage users to use this opportunity to test pg_upgrade for the upgrade from Beta1 or an earlier version of 9.0. Please report your results. However, I see the beta3 release notes are now on the web site so it seems too late to fix this. I'm a bit confused that pg_upgrade is advertised in this way, but is hidden in the manual under additionally supplied modules. If I was a new user, I would look in the administration chapter for any reference on how to do in-place upgrades. Is there any reason why pg_upgrade is not documented in the main manual? Regards Thomas -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] PostgreSQL 9.0 beta 3 release announcement
Thomas Kellerer wrote: Bruce Momjian wrote on 12.07.2010 21:34: Thom Brown wrote: Could someone clarify the info in this paragraph: Note that, due to a system catalog change, an initdb and database reload will be required for upgrading from 9.0Beta1. We encourage users to use this opportunity to test pg_upgrade for the upgrade from Beta2 or an earlier version of 9.0. Please report your results. This suggests that the system catalog change only occurred in Beta2, not Beta3. So if that's the case, why would I want to test pg_upgrade going from Beta2 to Beta3 if they use the same system catalog layout? Yes, this is wrong. It should be We encourage users to use this opportunity to test pg_upgrade for the upgrade from Beta1 or an earlier version of 9.0. Please report your results. However, I see the beta3 release notes are now on the web site so it seems too late to fix this. I'm a bit confused that pg_upgrade is advertised in this way, but is hidden in the manual under additionally supplied modules. If I was a new user, I would look in the administration chapter for any reference on how to do in-place upgrades. Is there any reason why pg_upgrade is not documented in the main manual? Well, pg_upgrade was only added in beta2, so maybe we need to go back and mention it as part of upgrading. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. + -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] PostgreSQL 9.0 beta1 and pg_upgrade
Hi, I was looking for the latest version of pg_migrator, and found in the latest release notes [1] that this functionality will be in contrib for 9.0. The 2010-04-30 snapshot of beta1 doesn't yet have pg_upgrade in contrib. I've had issues with pg_migrator on FreeBSD, similar to a bug report filed in June of last year [2], so I am eager to test this upgrade path. Are there plans to have pg_upgrade available in the betas before 9.0 is released? [1] - http://pgfoundry.org/frs/shownotes.php?release_id=1646 [2] - http://pgfoundry.org/tracker/index.php?func=detailaid=1010657group_id=1000235atid=890 Regards, -- Glen Barber -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] PostgreSQL 9.0 beta1 and pg_upgrade
Glen Barber wrote: Hi, I was looking for the latest version of pg_migrator, and found in the latest release notes [1] that this functionality will be in contrib for 9.0. The 2010-04-30 snapshot of beta1 doesn't yet have pg_upgrade in contrib. I've had issues with pg_migrator on FreeBSD, similar to a bug report filed in June of last year [2], so I am eager to test this upgrade path. Are there plans to have pg_upgrade available in the betas before 9.0 is released? [1] - http://pgfoundry.org/frs/shownotes.php?release_id=1646 [2] - http://pgfoundry.org/tracker/index.php?func=detailaid=1010657group_id=1000235atid=890 Yes. It will be added to PG 9.0 CVS within 18 hours, and should be in 9.0 beta2. I am in the middle of adding it to CVS now. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] PostgreSQL 9.0 beta1 and pg_upgrade
Bruce Momjian wrote: Glen Barber wrote: Are there plans to have pg_upgrade available in the betas before 9.0 is released? Yes. It will be added to PG 9.0 CVS within 18 hours, and should be in 9.0 beta2. I am in the middle of adding it to CVS now. Fantastic news. Thank you, Bruce. Regards, -- Glen Barber -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] PostgreSQL 9.0 - support for RANGE value PRECEDING window functions
Hi, I have a question about a feature in PostgreSQL 9.0. I am looking for support for windowing functions when using: RANGE BETWEEN value PRECEDING/FOLLOWING AND value PRECEDING/FOLLOWING The latest documentation: http://www.postgresql.org/docs/9.0/static/sql-expressions.html#SYNTAX-WINDOW-FUNCTIONS Says The value PRECEDING and value FOLLOWING cases are currently only allowed in ROWS mode. However, I have found this post: http://archives.postgresql.org/message-id/e08cc0400912310149me7150cek3c9aa92e4d396...@mail.gmail.com Which appears to provide a patch supporting: - allow all of RANGE BETWEEN value PRECEDING/FOLLOWING AND value PRECEDING/FOLLOWING. However, I cannot find any further information related to this feature. Can anyone confirm whether or not this feature will be available in PostgreSQL 9.0? Thanks, Dan Scott -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] PostgreSQL 9.0 - support for RANGE value PRECEDING window functions
Excerpts from Daniel Scott's message of lun may 10 13:20:06 -0400 2010: Says The value PRECEDING and value FOLLOWING cases are currently only allowed in ROWS mode. However, I have found this post: http://archives.postgresql.org/message-id/e08cc0400912310149me7150cek3c9aa92e4d396...@mail.gmail.com Which appears to provide a patch supporting: - allow all of RANGE BETWEEN value PRECEDING/FOLLOWING AND value PRECEDING/FOLLOWING. However, I cannot find any further information related to this feature. It was ripped out of the patch before commit because the implementation was not acceptable. Can anyone confirm whether or not this feature will be available in PostgreSQL 9.0? No. -- -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] PostgreSQL 9.0 - support for RANGE value PRECEDING window functions
Hi, On Mon, May 10, 2010 at 13:35, Alvaro Herrera alvhe...@alvh.no-ip.org wrote: It was ripped out of the patch before commit because the implementation was not acceptable. That's strange - the CommitFest says that it was committed and I can't find any mention of it being removed. Is there somewhere I can see a discussion of this? https://commitfest.postgresql.org/action/commitfest_view?id=5 Also, the documentation http://www.postgresql.org/docs/9.0/static/sql-expressions.html#SYNTAX-WINDOW-FUNCTIONS shows: [ RANGE | ROWS ] BETWEEN frame_start AND frame_end Can you point me to the right place for getting this changed to remove RANGE. Maybe the developer mailing list? Thanks, Dan Scott -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] PostgreSQL 9.0 - support for RANGE value PRECEDING window functions
Daniel Scott djsc...@mit.edu writes: On Mon, May 10, 2010 at 13:35, Alvaro Herrera alvhe...@alvh.no-ip.org wrote: It was ripped out of the patch before commit because the implementation was not acceptable. That's strange - the CommitFest says that it was committed and I can't find any mention of it being removed. Is there somewhere I can see a discussion of this? Look into the pgsql-hackers thread about it. (The commitfest notes are not meant to be a complete record of the mailing list discussions.) I think the relevant part starts here: http://archives.postgresql.org/pgsql-hackers/2010-02/msg00540.php Also, the documentation http://www.postgresql.org/docs/9.0/static/sql-expressions.html#SYNTAX-WINDOW-FUNCTIONS shows: [ RANGE | ROWS ] BETWEEN frame_start AND frame_end Can you point me to the right place for getting this changed to remove RANGE. Maybe the developer mailing list? There's nothing to remove there, since RANGE is in fact valid with many of the alternatives for frame_start and frame_end. It would be very awkward to try to show this limitation as part of the syntax diagram, so it's just specified in the text. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [pgsql-advocacy] [GENERAL] PostgreSQL 9.0
Bruce, Having contributors bought out was always one of our three risks, the other two being patent and trademark attacks. Not sure what we can really do about them. Actually, the potential for trademark attacks is minimal to nonexistant according to the attorney's report. So I'm not worrying about it. Patent attacks are no more a risk for us than they are for every other OSS project, and the answer for these is to support the anti-patent organizations. Overall, I think we're in a good position in that there are a lot of attacks which could *hurt* PostgreSQL, but none which are a guarenteed kill, and the public knowledge of an attack could easily cause our users and enemies of the attacker, and the OSS legal community, to rally to our defense and support. This makes any attack a risky proposition for the attacker. Our #1 best defense is to make sure that as many companies as possible have invested in making PostgreSQL an integral part of their infrastructure and/or product line. -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [GENERAL] PostgreSQL 9.0
On 30 Jan 2007 12:15:17 -0800, Karen Hill [EMAIL PROTECTED] wrote: On Jan 29, 11:06 pm, [EMAIL PROTECTED] (Dawid Kuroczko) wrote: * updatable views [ or am I missing something? ] -- it seems to me they were close to be completed, but I don't remember if they were completed and committed or not. PostgreSQL has updatable views via the rules system. I use updatable views all the time in postgres. The point is that you can't do things with the rule system reliable the SQL standard tells us to do. The CHECK OPTION is an example, this can't be modeled using rules only. Bernd ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [GENERAL] PostgreSQL 9.0
Personally I'm missing two things, which were discussed in the past, but would be nice to have: * more efficient storage of varlen data -- some time ago there were ideas to get rid of constant 4-bytes for length and use more elastic approach. Smaller tables, bigger performance. * updatable views [ or am I missing something? ] -- it seems to me they were close to be completed, but I don't remember if they were completed and committed or not. I'm missing stuff like true polymorphic function arguments and return values (where I can mix different datatypes and do variable number of parameters), also I personally hate 'select * from my_func() as table(x varchar)' syntax... system should be able to omit the table structure definition and pick it up from function return. Oh well, back to work. Where do we submit wishlist entries, anyway? Peter ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [GENERAL] PostgreSQL 9.0
Dawid Kuroczko [EMAIL PROTECTED] writes: * updatable views [ or am I missing something? ] -- it seems to me they were close to be completed, but I don't remember if they were completed and committed or not. Something different than rules? (http://www.postgresql.org/docs/8.2/interactive/rules.html) (They exist for a while, I've just linked the latest released docs...) -- Jorge Godoy [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [GENERAL] PostgreSQL 9.0
Jorge Godoy wrote: Dawid Kuroczko [EMAIL PROTECTED] writes: * updatable views [ or am I missing something? ] -- it seems to me they were close to be completed, but I don't remember if they were completed and committed or not. Something different than rules? (http://www.postgresql.org/docs/8.2/interactive/rules.html) (They exist for a while, I've just linked the latest released docs...) Quite. Rules are not updateable views. Rules are a hacked up way to create an updateable view. The patch as discussed IIRC, would make the rules automatically. Sincerely, Joshua D. Drake ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org/
Re: [GENERAL] PostgreSQL 9.0
Jorge Godoy wrote: Dawid Kuroczko [EMAIL PROTECTED] writes: * updatable views [ or am I missing something? ] -- it seems to me they were close to be completed, but I don't remember if they were completed and committed or not. Something different than rules? (http://www.postgresql.org/docs/8.2/interactive/rules.html) (They exist for a while, I've just linked the latest released docs...) See http://developer.postgresql.org/index.php/Updatable_views for further wisdom. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [GENERAL] PostgreSQL 9.0
On Tue, 2007-01-30 at 02:35 -0800, Joshua D. Drake wrote: Something different than rules? (http://www.postgresql.org/docs/8.2/interactive/rules.html) (They exist for a while, I've just linked the latest released docs...) Quite. Rules are not updateable views. Rules are a hacked up way to create an updateable view. I wouldn't go that far. Rules can do things that updatable views can't do. Sometimes a view can't be updatable because an update to that view would be ambiguous (as far as the system knows), but you can still use the well-defined rules system to *tell* the system what you want an update to mean. Updatable views provide a subset of the functionality of rules, but they do it automatically without much effort on the part of the DBA. That's great, but it won't replace rules. Regards, Jeff Davis ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] PostgreSQL 9.0
On Jan 29, 11:06 pm, [EMAIL PROTECTED] (Dawid Kuroczko) wrote: * updatable views [ or am I missing something? ] -- it seems to me they were close to be completed, but I don't remember if they were completed and committed or not. PostgreSQL has updatable views via the rules system. I use updatable views all the time in postgres. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] PostgreSQL 9.0
Ron Johnson wrote: Who would they target anyways? There's no one company They could buy out CommandPrompt and EnterpriseDB... The buyouts wouldn't *kill* pg, but they would wound it mightily. I don't think so. High-profile and high priced buyouts of CommandPrompt and EnterpriseDB would be great for postgresql. It would be a strong motivation for entrepreneurs to start postgresql companies, developers to build postgresql expertise, VCs to invest in postgresql companies. And guys like Pervasive would be kicking themselves for not keeping sticking with it. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [GENERAL] PostgreSQL 9.0
On 30 Jan 2007 12:15:17 -0800, Karen Hill [EMAIL PROTECTED] wrote: On Jan 29, 11:06 pm, [EMAIL PROTECTED] (Dawid Kuroczko) wrote: * updatable views [ or am I missing something? ] -- it seems to me they were close to be completed, but I don't remember if they were completed and committed or not. PostgreSQL has updatable views via the rules system. I use updatable views all the time in postgres. That is not a point really. This todo is not about implementing rule system which PostgreSQL already has. It's about implementing infrastructure to set up updatable views automatically, as the standard dictates. And this is a feaure PostgreSQL lacks. If you want updatable views you have to issue couple of CREATE RULEs apart from CREATE VIEW. The point is that you could create updatable views with sole CREATE VIEW command. Another example is table partitioning which PostgreSQL has and doesn't have. You can set up table partitioning with clever set of triggers and table inheritance, but it lacks explicit DDLs to do so. Regards, Dawid ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [GENERAL] PostgreSQL 9.0
On 1/30/07, Ron Mayer [EMAIL PROTECTED] wrote: Ron Johnson wrote: Who would they target anyways? There's no one company They could buy out CommandPrompt and EnterpriseDB... The buyouts wouldn't *kill* pg, but they would wound it mightily. I don't think so. High-profile and high priced buyouts of CommandPrompt and EnterpriseDB would be great for postgresql. It would be a strong motivation for entrepreneurs to start postgresql companies, developers to build postgresql expertise, VCs to invest in postgresql companies. And guys like Pervasive would be kicking themselves for not keeping sticking with it. One would think that with the acquisiton of Berkeley DB and InnoDB one should see a flourish of database engine startups, but I seem to have missed that. My point is, its not about throwing money at a problem. PostgreSQL seems to be having right people at the right place and benefits from it. They do the hard work, they do it well, hence 8.0, 8.1, 8.2 and upcoming 8.3 release. If you buy these people out, it will take time to find and teach new ones. Writing RDBMS is not dusting crops, ya know. ;))) Regards, Dawid PS: I guess this thread belongs in advocacy, please update To: headers accordingly. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [pgsql-advocacy] [GENERAL] PostgreSQL 9.0
Dawid Kuroczko wrote: On 1/30/07, Ron Mayer [EMAIL PROTECTED] wrote: Ron Johnson wrote: Who would they target anyways? There's no one company They could buy out CommandPrompt and EnterpriseDB... The buyouts wouldn't *kill* pg, but they would wound it mightily. I don't think so. High-profile and high priced buyouts of CommandPrompt and EnterpriseDB would be great for postgresql. It would be a strong motivation for entrepreneurs to start postgresql companies, developers to build postgresql expertise, VCs to invest in postgresql companies. And guys like Pervasive would be kicking themselves for not keeping sticking with it. One would think that with the acquisiton of Berkeley DB and InnoDB one should see a flourish of database engine startups, but I seem to have missed that. My point is, its not about throwing money at a problem. PostgreSQL seems to be having right people at the right place and benefits from it. They do the hard work, they do it well, hence 8.0, 8.1, 8.2 and upcoming 8.3 release. If you buy these people out, it will take time to find and teach new ones. Writing RDBMS is not dusting crops, ya know. ;))) Having contributors bought out was always one of our three risks, the other two being patent and trademark attacks. Not sure what we can really do about them. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] PostgreSQL 9.0
Dawid Kuroczko [EMAIL PROTECTED] writes: My point is, its not about throwing money at a problem. PostgreSQL seems to be having right people at the right place and benefits from it. They do the hard work, they do it well, hence 8.0, 8.1, 8.2 and upcoming 8.3 release. If you buy these people out, it will take time to find and teach new ones. Writing RDBMS is not dusting crops, ya know. ;))) Buying out a company wouldn't affect dedicated people; they'd find a job somewhere else and keep right at it. Companies have disappeared on us before (Great Bridge, Pervasive) and the project is still here. I think one significant difference between us and MySQL is that that project probably *could* be killed by acquiring and shutting down one company. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[GENERAL] PostgreSQL 9.0
I was just looking at all the upcoming features scheduled to make it into 8.3, and with all those goodies, wouldn't it make sense for this to be a 9.0 release instead of an 8.3? It looks like postgresql is rapidly catching up to oracle if 8.3 branch gets every feature scheduled for it. About the only big features pg 8.3 doesn't have is materialized views and RMAN.. Now that PostgreSQL is getting so close to oracle functionality, is there any worry in the community that oracle will begin to target postgres like they're targeting mySQL? regards, karen ---(end of broadcast)--- TIP 6: explain analyze is your friend
[GENERAL] PostgreSQL 9.0
I was just looking at all the upcoming features scheduled to make it into 8.3, and with all those goodies, wouldn't it make sense for this to be a 9.0 release instead of an 8.3? It looks like postgresql is rapidly catching up to oracle if 8.3 branch gets every feature scheduled for it. About the only big features pg 8.3 doesn't have is materialized views and RMAN.. Now that PostgreSQL is getting so close to oracle functionality, is there any worry in the community that oracle will begin to target postgres like they're targeting mySQL? regards, karen ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [GENERAL] PostgreSQL 9.0
No. Postgres does not represent an economic entity that can compete for $ $ with Oracle. It's also not nearly as popular. And I mean that in a very pop- culture way. How long did it take Oracle to support Linux? Only when it became popular to do so. Who would they target anyways? There's no one company On Jan 29, 2007, at 4:27 PM, Karen Hill wrote: I was just looking at all the upcoming features scheduled to make it into 8.3, and with all those goodies, wouldn't it make sense for this to be a 9.0 release instead of an 8.3? It looks like postgresql is rapidly catching up to oracle if 8.3 branch gets every feature scheduled for it. About the only big features pg 8.3 doesn't have is materialized views and RMAN.. Now that PostgreSQL is getting so close to oracle functionality, is there any worry in the community that oracle will begin to target postgres like they're targeting mySQL? regards, karen ---(end of broadcast)--- TIP 6: explain analyze is your friend QIDX:b07f206845737e76a8dbfbcfaae7837f ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [GENERAL] PostgreSQL 9.0
On Jan 29, 2007, at 4:27 PM, Karen Hill wrote: I was just looking at all the upcoming features scheduled to make it into 8.3, and with all those goodies, wouldn't it make sense for this to be a 9.0 release instead of an 8.3? It looks like postgresql is rapidly catching up to oracle if 8.3 branch gets every feature scheduled for it. At one point there was discussion about using changes to the first digit to indicate that a dump and restore was needed because of an on disk format change and that changes to the second digit would indicate that only catalog entries have changed and that an upgrade tool (that doesn't exist yet) could be used to make the changes with minimal downtime. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] PostgreSQL 9.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/29/07 16:05, tom wrote: No. Postgres does not represent an economic entity that can compete for $$ with Oracle. It's also not nearly as popular. And I mean that in a very pop-culture way. How long did it take Oracle to support Linux? Only when it became popular to do so. Who would they target anyways? There's no one company They could buy out CommandPrompt and EnterpriseDB... The buyouts wouldn't *kill* pg, but they would wound it mightily. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFvnRGS9HxQb37XmcRAjA7AJ96LsBV2af16AjNcuSMLnQT6TvhmgCdESzN 17BSJ6ujxPwkebKwCbBEuy4= =kZ5Q -END PGP SIGNATURE- ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] PostgreSQL 9.0
On Mon, Jan 29, 2007 at 01:27:19PM -0800, Karen Hill wrote: there any worry in the community that oracle will begin to target postgres like they're targeting mySQL? I attended a big ora conference in 2006 and was a bit surprised to observe the fact that ora corp keynote addresses did not even mention a db. The big focus was the apps, their future. I think they have resigned themselves to those weak db sales. They can just charge what they like this week to the people who live on their apps. Mogens Norgaard wrote in Tales of the Oak Table, 2004, But Oracle needs to reinvent itself. No company can survive on a database only revenue stream in the next 10 years. That said, probably, lasts gasps from a legacy system. I'm wondering when ora will open up its code ala sun/solaris. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] PostgreSQL 9.0
Ray Stell wrote: On Mon, Jan 29, 2007 at 01:27:19PM -0800, Karen Hill wrote: there any worry in the community that oracle will begin to target postgres like they're targeting mySQL? I attended a big ora conference in 2006 and was a bit surprised to observe the fact that ora corp keynote addresses did not even mention a db. The big focus was the apps, their future. I think they have resigned themselves to those weak db sales. They can just charge what they like this week to the people who live on their apps. Absolutely! -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org/
Re: [GENERAL] PostgreSQL 9.0
On 1/29/07, Ray Stell [EMAIL PROTECTED] wrote: That said, probably, lasts gasps from a legacy system. I'm wondering when ora will open up its code ala sun/solaris. According to a recent Gartner study, Oracle has 48% market share (in other words they are the market leader by a margin of 26%). http://www.gartner.com/press_releases/asset_152619_11.html I am pretty convinced Oracle wouldn't open source their database code. The competition would tear them apart by reinventing the Oracle Database. If you want open source Oracle code then download BDB or InnoDB ;), I think that is as close as it gets. -- Chad http://www.postgresqlforums.com/
Re: [GENERAL] PostgreSQL 9.0
On Mon, 29 Jan 2007, Bruno Wolff III wrote: At one point there was discussion about using changes to the first digit to indicate that a dump and restore was needed because of an on disk format change and that changes to the second digit would indicate that only catalog entries have changed and that an upgrade tool (that doesn't exist yet) could be used to make the changes with minimal downtime. Bruno, So, to migrate from -8.1.4 to -8.2.1 I don't need to dump and restore? Thanks, Rich -- Richard B. Shepard, Ph.D. |The Environmental Permitting Applied Ecosystem Services, Inc.| Accelerator(TM) http://www.appl-ecosys.com Voice: 503-667-4517 Fax: 503-667-8863 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org/
Re: [GENERAL] PostgreSQL 9.0
On Jan 30, 2007, at 8:38 , Rich Shepard wrote: On Mon, 29 Jan 2007, Bruno Wolff III wrote: At one point there was discussion about using changes to the first digit to indicate that a dump and restore was needed because of an on disk format change and that changes to the second digit would indicate that only catalog entries have changed and that an upgrade tool (that doesn't exist yet) could be used to make the changes with minimal downtime. Bruno, So, to migrate from -8.1.4 to -8.2.1 I don't need to dump and restore? It was *discussed*. 8.1 to 8.2 (as does any move from M.x to M.y where x ≠ y) requires a dump and reload. Michael Glaesemann grzm seespotcode net ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org/
Re: [GENERAL] PostgreSQL 9.0
On Tue, 30 Jan 2007, Michael Glaesemann wrote: It was *discussed*. 8.1 to 8.2 (as does any move from M.x to M.y where x y) requires a dump and reload. Michael, That's what I thought. However, it never hurts to ask. :-) Rich -- Richard B. Shepard, Ph.D. |The Environmental Permitting Applied Ecosystem Services, Inc.| Accelerator(TM) http://www.appl-ecosys.com Voice: 503-667-4517 Fax: 503-667-8863 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [GENERAL] PostgreSQL 9.0
On Jan 30, 2007, at 8:51 , Rich Shepard wrote: On Tue, 30 Jan 2007, Michael Glaesemann wrote: It was *discussed*. 8.1 to 8.2 (as does any move from M.x to M.y where x y) requires a dump and reload. Michael, That's what I thought. However, it never hurts to ask. :-) Or check the release notes :) Michael Glaesemann grzm seespotcode net ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [GENERAL] PostgreSQL 9.0
On Tue, 30 Jan 2007, Michael Glaesemann wrote: Or check the release notes :) Oooh! What a novel idea. :-) I don't have the time -- or the need right now -- to upgrade so it's on the back burner. Thanks, Michael, Rich -- Richard B. Shepard, Ph.D. |The Environmental Permitting Applied Ecosystem Services, Inc.| Accelerator(TM) http://www.appl-ecosys.com Voice: 503-667-4517 Fax: 503-667-8863 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [GENERAL] PostgreSQL 9.0
On Mon, Jan 29, 2007 at 15:51:54 -0800, Rich Shepard [EMAIL PROTECTED] wrote: On Tue, 30 Jan 2007, Michael Glaesemann wrote: It was *discussed*. 8.1 to 8.2 (as does any move from M.x to M.y where x y) requires a dump and reload. Michael, That's what I thought. However, it never hurts to ask. :-) I figured that mentionioning you need a tool that doesn't exist would make it clear that this was proposed for the future and not current reality. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] PostgreSQL 9.0
On 29 Jan 2007 13:25:31 -0800, Karen Hill [EMAIL PROTECTED] wrote: I was just looking at all the upcoming features scheduled to make it into 8.3, and with all those goodies, wouldn't it make sense for this to be a 9.0 release instead of an 8.3? It looks like postgresql is rapidly catching up to oracle if 8.3 branch gets every feature scheduled for it. Well I see it in two ways. For one, the features are certainly great and a significant advance. This alone could mandate version bump to 9.0. On the other hand, the 8.x line is so successful I would like it to stay for a copule revisions more. Well, it does have a nice feeling about it: What? Yeah, it does support windowing function, we've introduced them around version 8.3. Naah, no big deal, wait for the version 8.4, you'll be surprosed. Naah, we keep version 9.0 for truly significant changes. And I must say, I do like it. About the only big features pg 8.3 doesn't have is materialized views and RMAN.. Personally I'm missing two things, which were discussed in the past, but would be nice to have: * more efficient storage of varlen data -- some time ago there were ideas to get rid of constant 4-bytes for length and use more elastic approach. Smaller tables, bigger performance. * updatable views [ or am I missing something? ] -- it seems to me they were close to be completed, but I don't remember if they were completed and committed or not. Regards, Dawid ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [GENERAL] PostgreSQL 9.0
Karen Hill wrote: I was just looking at all the upcoming features scheduled to make it into 8.3, and with all those goodies, wouldn't it make sense for this to be a 9.0 release instead of an 8.3? If every release got all the features scheduled for it, we'd be at version 37.0 now. At this point, there is no telling what will be in 8.3. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [GENERAL] PostgreSQL 9.0
am Tue, dem 30.01.2007, um 8:47:48 +0100 mailte Peter Eisentraut folgendes: Karen Hill wrote: I was just looking at all the upcoming features scheduled to make it into 8.3, and with all those goodies, wouldn't it make sense for this to be a 9.0 release instead of an 8.3? If every release got all the features scheduled for it, we'd be at version 37.0 now. At this point, there is no telling what will be in 8.3. Full ACK, we have a wishlist with many nice features. That's all. Andreas -- Andreas Kretschmer Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: - Header) GnuPG-ID: 0x3FFF606C, privat 0x7F4584DA http://wwwkeys.de.pgp.net ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
