Thanks for you detail mail on this. We will look into 8.1.4 and start using it. Meanwhile, we would like to know about this error. When I start PostgreSQL service, the below error message is displayed and finally service didn't started. The PostgreSQL Database Server 8.0 service of a local computer cannot begin. Error 1069: Service was not able to begin because it had failed in logon. Any idea about this error ?. Hope when we start service it checks for Windows authentication rather than DB authentication. Not Sure!. Regards, Ravi -----Original Message----- From: Jim Nasby [mailto:jim@xxxxxxxxx] Sent: Wednesday, October 11, 2006 7:29 AM To: Ravindran G - TLS, Chennai. Cc: pgsql-general@xxxxxxxxxxxxxx; Hari Krishna D - TLS , Chennai; Sasikala V - TLS , Chennai Subject: Re: [GENERAL] [PERFORM] Postgre 8.0 Installation - Issues PostgreSQL doesn't really have any unstable versions (unless you're talking about code right out of CVS). The closest you might come will be the initial release of a major version, or of course a beta/ release candidate. (Note that the first "dot" indicates a major version for PostgreSQL. 8.0 is a major version, as is 8.1). But even our betas are generally very solid and stable. If you're looking for the utmost in stability, you probably want to go with 8.1.4 (or 8.1.5, which should be out RSN). What does happen from time-to-time is a complex bug (usually some kind of a race condition) that has the potential to corrupt data will be discovered. These are generally very hard to reproduce, and usually go back a number of major versions. This is why it's important to update to newer minor versions (ie: 8.1.3 to 8.1.4) when they come out. Another issue you'll be facing is that windows support is fairly new; 8.0 was the first release that had it. So the performance of the windows version has been getting better, and some minor bugs are still being found and fixed. I know that may sound a bit scary, but the truth is it's no different for commercial databases; they just hide it from you. Of course, unless you've discovered some magic process for producing bug-free code, you'll undoubtedly have to send out bug fixes for your product as well. ;) It's very painless to do a minor version upgrade of PostgreSQL, so it makes sense to include that with the updates you send out for your product. On Oct 10, 2006, at 9:27 AM, Ravindran G - TLS, Chennai. wrote: > Thanks for your comments and moving it to general group. > > We would like to know which is the most stable version in > Postgresql ?. > Because Postgresql may undergo changes and will have the version > incremented. In this case, do we need to do the upgrade > frequently ?. Of > course, its good have the latest version but this cannot be done > each and > every time after deploying our application to end customers. > > Please advise. > > Regards, Ravi > > > -----Original Message----- > From: Jim C. Nasby [mailto:jim@xxxxxxxxx] > Sent: Tuesday, October 10, 2006 7:46 PM > To: Ravindran G - TLS, Chennai. > Cc: pgsql-general@xxxxxxxxxxxxxx; Hari Krishna D - TLS , Chennai; > Sasikala V > - TLS , Chennai > Subject: Re: [PERFORM] Postgre 8.0 Installation - Issues > > > Moving to -general. > > On Tue, Oct 10, 2006 at 04:17:06PM +0530, Ravindran G - TLS, > Chennai. wrote: >> All, >> >> We are facing few issues while we install Postgres 8.0 in Windows >> 2000 >> Japanese OS. Installer kit name : postgresql-8.0-ja > > Is there a reason you're not using 8.1.4? 8.0 was the first windows > release, and as such there's a number of issues that were improved in > 8.1. You should at least be using the latest 8.0 version (8.0.8). > >> Scenario 1: While installing PostGRE 8.0, we got an logon failure >> at the > end > > BTW, it's PostgreSQL or Postgres. PostGRE doesn't exist... > >> of installing the component telling that it failed to produce the >> process >> for initdb and also that the user name was not able to be >> recognized or > the >> password is wrong. After the OK button was clicked the whole process > rolled >> back automatically and the PostGRE got uninstalled. > > Make sure that you have the right password for the account that > PostgreSQL will be running under. I often find it's easiest to just > delete that account and let the installer create it for me. > >> Scenario 2: In one of the computers we managed to install the >> PostGRE 8.0 >> but the database initialization could not be performed. While >> creating the >> database using the Credb patch we got an error telling that the >> tables > were >> missing and the connection with the local host failed. >> >> Scenario 3: For one of the machines the database has also been >> created but >> once the system is restarted the PostGRE does not work and we get >> the same >> error as in the Scenario2. > > These could be issues surrounding administrator rights. PostgreSQL > will > refuse to start if the account it's running under has Administrator > rights. > >> Please shed some light on this. If this question is not relevant >> to this >> group, please redirect us... >> >> Thanks and regards, >> Ravi >> DISCLAIMER >> The contents of this e-mail and any attachment(s) are confidential >> and > intended for the >> >> named recipient(s) only. It shall not attach any liability on the > originator or HCL or its >> >> affiliates. Any views or opinions presented in this email are >> solely those > of the author and >> >> may not necessarily reflect the opinions of HCL or its affiliates. >> Any > form of reproduction, >> >> dissemination, copying, disclosure, modification, distribution >> and / or > publication of this >> >> message without the prior written consent of the author of this e- >> mail is > strictly >> >> prohibited. If you have received this email in error please delete >> it and > notify the sender >> >> immediately. Before opening any mail and attachments please check >> them for > viruses and >> >> defect. >> >> ---------------------------(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 >> > > -- > Jim Nasby jim@xxxxxxxxx > EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) > > ---------------------------(end of > broadcast)--------------------------- > TIP 2: Don't 'kill -9' the postmaster > -- Jim Nasby jim@xxxxxxxxx EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
