Thread: Re: win32 pgsql not installable
>I know I'm going to go on some people's nerves, but it's necessary. > >With the current "run-as-non-admin" restriction the windows installer >doesn't work, and it will probably be ridiculously difficult >to make it >work unless this restriction is redesigned. Not commenting on the other parts, but *huh*? The windows installer works just fine. It does require that you manually set up a non-admin account, but it certainly *works*... >I don't see any point in restricting postgres.exe (i.e. the >single user >non-communicating version) to non-superusers. Installations >are usually >executed with admin privileges (non-admins won't be able to create >services), and currently it fails to initialize the cluster with that >d***d message. Consequently, it rolls back the complete installation >leaving me at point zero. The installer already takes care of this, and executes initdb with the permissions of the service account, not the installer account. The installer should probably check for admin permissions before accepting the account, though. If this does not work for you, it's a bug in the installer, or an incorrectly set up service account. I'm no longer commenting on the other part of the discussion :-), but the workarounds are in place and working in the installer. Assuming you do the service install, otherwise you have to do it manually. //Magnus
> -----Original Message----- > From: Andreas Pflug [mailto:pgadmin@pse-consulting.de] > Sent: 27 July 2004 23:55 > To: pgsql-hackers-win32@postgresql.org > Cc: Magnus Hagander; Dave Page > Subject: win32 pgsql not installable > > I know I'm going to go on some people's nerves, but it's necessary. > > With the current "run-as-non-admin" restriction the windows > installer doesn't work, and it will probably be ridiculously > difficult to make it work unless this restriction is redesigned. It's a pita for ad-hoc use, but installation and running as a service works perfectly here. > I don't see any point in restricting postgres.exe (i.e. the > single user non-communicating version) to non-superusers. > Installations are usually executed with admin privileges > (non-admins won't be able to create services), and currently > it fails to initialize the cluster with that d***d message. > Consequently, it rolls back the complete installation leaving > me at point zero. Whats the error? Regards, Dave
I know I'm going to go on some people's nerves, but it's necessary. With the current "run-as-non-admin" restriction the windows installer doesn't work, and it will probably be ridiculously difficult to make it work unless this restriction is redesigned. I don't see any point in restricting postgres.exe (i.e. the single user non-communicating version) to non-superusers. Installations are usually executed with admin privileges (non-admins won't be able to create services), and currently it fails to initialize the cluster with that d***d message. Consequently, it rolls back the complete installation leaving me at point zero. If I was an average win32 user testing pgsql, this would be the end of my attempt to install it. Regards, Andreas
Dave Page wrote: > > > >>-----Original Message----- >>From: Andreas Pflug [mailto:pgadmin@pse-consulting.de] >>Sent: 27 July 2004 23:55 >>To: pgsql-hackers-win32@postgresql.org >>Cc: Magnus Hagander; Dave Page >>Subject: win32 pgsql not installable >> >>I know I'm going to go on some people's nerves, but it's necessary. >> >>With the current "run-as-non-admin" restriction the windows >>installer doesn't work, and it will probably be ridiculously >>difficult to make it work unless this restriction is redesigned. > > > It's a pita for ad-hoc use, but installation and running as a service > works perfectly here. > > >>I don't see any point in restricting postgres.exe (i.e. the >>single user non-communicating version) to non-superusers. >>Installations are usually executed with admin privileges >>(non-admins won't be able to create services), and currently >>it fails to initialize the cluster with that d***d message. >>Consequently, it rolls back the complete installation leaving >>me at point zero. > > > Whats the error? Just posted the details how I succeeded in the end. Regards, Andreas
Magnus Hagander wrote: > >I know I'm going to go on some people's nerves, but it's necessary. > > > >With the current "run-as-non-admin" restriction the windows installer > >doesn't work, and it will probably be ridiculously difficult > >to make it > >work unless this restriction is redesigned. > > Not commenting on the other parts, but *huh*? The windows installer > works just fine. It does require that you manually set up a non-admin > account, but it certainly *works*... And you have to tell the system that user can start a service. > >I don't see any point in restricting postgres.exe (i.e. the > >single user > >non-communicating version) to non-superusers. Installations > >are usually > >executed with admin privileges (non-admins won't be able to create > >services), and currently it fails to initialize the cluster with that > >d***d message. Consequently, it rolls back the complete installation > >leaving me at point zero. > > The installer already takes care of this, and executes initdb with the > permissions of the service account, not the installer account. > The installer should probably check for admin permissions before > accepting the account, though. > If this does not work for you, it's a bug in the installer, or an > incorrectly set up service account. > > I'm no longer commenting on the other part of the discussion :-), but > the workarounds are in place and working in the installer. Assuming you > do the service install, otherwise you have to do it manually. I have a machine with 256MB RAM and had a lot of popup failure error messages while it was testing the shared buffer value during initdb, and the initdb failed too. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Andreas Pflug wrote: > I know I'm going to go on some people's nerves, but it's necessary. > > With the current "run-as-non-admin" restriction the windows installer > doesn't work, and it will probably be ridiculously difficult to make it > work unless this restriction is redesigned. > > I don't see any point in restricting postgres.exe (i.e. the single user > non-communicating version) to non-superusers. Installations are usually > executed with admin privileges (non-admins won't be able to create > services), and currently it fails to initialize the cluster with that > d***d message. Consequently, it rolls back the complete installation > leaving me at point zero. > > If I was an average win32 user testing pgsql, this would be the end of > my attempt to install it. I added a non-admin user but said they could create serviced. That go the install started, but the initdb failed with no real error message. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
> > >I know I'm going to go on some people's nerves, but it's necessary. > > > > > >With the current "run-as-non-admin" restriction the > windows installer > > >doesn't work, and it will probably be ridiculously > difficult to make > > >it work unless this restriction is redesigned. > > > > Not commenting on the other parts, but *huh*? The windows installer > > works just fine. It does require that you manually set up a > non-admin > > account, but it certainly *works*... > > And you have to tell the system that user can start a service. Yes and no. The *service account* needs permissions to "Log On as a Service". It specifically does *NOT* need permission to start/stop services, or any other admin privileges. The *install account* needs permissions to install files, *install* services and start/stop services. These accounts should always be different. The install account is the administrator account, or whatever other accuont you use to setup your system. The service account would typicall be called "postgres". //Magnus
Magnus Hagander wrote: > > > >I know I'm going to go on some people's nerves, but it's necessary. > > > > > > > >With the current "run-as-non-admin" restriction the > > windows installer > > > >doesn't work, and it will probably be ridiculously > > difficult to make > > > >it work unless this restriction is redesigned. > > > > > > Not commenting on the other parts, but *huh*? The windows installer > > > works just fine. It does require that you manually set up a > > non-admin > > > account, but it certainly *works*... > > > > And you have to tell the system that user can start a service. > > Yes and no. > The *service account* needs permissions to "Log On as a Service". It > specifically does *NOT* need permission to start/stop services, or any > other admin privileges. Right, under Administrative Tools, Local Security, User Rights Assignment, I added 'postgres' to "Log On as a Service". -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Guys ! Please take into account that users will not be able to be run the Postgres service on Win XP Home. XP Home does not offer the local security policy editor and therefore it is not possible to have the logon-as-service right for any user except administrators (I'm not shure if it would be possible to assign the approriate rights programmatically - maybe this option should be included in the installer then ?). By default, you can only create two type of users, namely users with administrative rights and so-called "limited" users. Limited users also cannot, for instance, create file underneath the program files folder etc., making it impossible to install Postgres there (it works in different locations, however). I certainly do not want to start a discussion about using XP Home vs. using XP Professional here (most of us would of course never use XP Home); I just wanted to ask if you are aware of this restrictions. Timezone recognitions seems to be a general problem as well. If I run initdb on my German Win XP, I get "could not recognize system timezone, defaulting to "Etc/GMT-1". My system timezone is "Westeuropäische Sommerzeit" (GMT+02:00) or "Westeuropäische Normalzeit" (GMT+01:00). In the timezone settings dialog, Windows shows "(GMT+01:00) Amsterdam, Berlin, Bern, Rom, Stockholm, Wien". The correct timezone would be "Europe/Berlin" in my case (I know I can set it manually). I guess the localized descriptions are likely to make a unified recognition very hard... Do you plan any improvements in this area ? Apart from these two points: has anyone done Windows vs. Unix performance tests yet for Postgres 7.5 ? And to the developers: what is your planned timeframe for 7.5, if any ? Regards, Christian.
Bruce Momjian wrote: >Right, under Administrative Tools, Local Security, User Rights >Assignment, I added 'postgres' to "Log On as a Service". > > That is remarkably obscure, at least for the average user (in this case, me.) Is there really no way to automate this in the installer? If not, I will add my vote to the clamour for relaxing the runas restrictions. cheers andrew
> -----Original Message----- > From: pgsql-hackers-win32-owner@postgresql.org > [mailto:pgsql-hackers-win32-owner@postgresql.org] On Behalf > Of Andrew Dunstan > Sent: 28 July 2004 13:37 > To: pgsql-hackers-win32@postgresql.org > Subject: Re: [pgsql-hackers-win32] win32 pgsql not installable > > > > Bruce Momjian wrote: > > >Right, under Administrative Tools, Local Security, User Rights > >Assignment, I added 'postgres' to "Log On as a Service". > > > > > > > That is remarkably obscure, at least for the average user (in > this case, > me.) Is there really no way to automate this in the > installer? If not, I will add my vote to the clamour for > relaxing the runas restrictions. Yes, it can be done by the installer - it's on the todo list. Regards, Dave. BTW, thanks for picking up the rm thing :-)
> Guys ! Please take into account that users will not be able to be run the > Postgres service on Win XP Home. XP Home does not offer the local security > policy editor and therefore it is not possible to have the logon-as- > service > right for any user except administrators (I'm not shure if it would be > possible to assign the approriate rights programmatically - maybe this > option should be included in the installer then ?). By default, you can > only > create two type of users, namely users with administrative rights and > so-called "limited" users. Limited users also cannot, for instance, create > file underneath the program files folder etc., making it impossible to > install Postgres there (it works in different locations, however). > I certainly do not want to start a discussion about using XP Home vs. > using Officially, XP Home is not supported (XP home has a 5 connection cap, btw). IMO, the only reason XP home is interesting is for cases where pg might be packaged with an application. Right now, to run it on XP home you have create a limited user, log on as that user, create the data folder, and run initdb. It's nasty. I've played with it a bit...try manually entering the log in to the service manger...on XP pro the system grants the logon right here if the user doesn't have it. Otherwise, might as well give up on the service idea. Just have run pg_ctl start via batch when system starts up...this is almost as good for simple purposes. I think the ultimate solution to this problem is to beef up the standalone backend functionality so that apps can just pipe to postgres.exe and not bother with the listening server (and security implications thereof). In this case, the packaged app problem would be solved and there would be no reason to run pg as a service for XP home (there really isn't now). Merlin
Andrew Dunstan wrote: > > > Bruce Momjian wrote: > > >Right, under Administrative Tools, Local Security, User Rights > >Assignment, I added 'postgres' to "Log On as a Service". > > > > > > > That is remarkably obscure, at least for the average user (in this case, > me.) Is there really no way to automate this in the installer? If not, > I will add my vote to the clamour for relaxing the runas restrictions. Being an XP newbie, I was proud I found it. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
>From: Christian Klemke >Guys ! Please take into account that users will not be able to be run the >Postgres service on Win XP Home. XP Home does not offer the local security >policy editor and therefore it is not possible to have the logon-as-service >right for any user except administrators ......... I tried for several days to install the w32-postgres project. Finally downloaded Powergres which is now running without trouble on the HP notebook. From your post I think the trouble is in the support ( lack of) for XP-Home. I think there will be many with notbooks who would like to use postgres as a development tool possibly with the view that the final application will run on a XP/2000 or Linux server. With all the hard work done and a great product nearly available it would appear that the security issues are really hobbling the finalisation of the w32 project. Richard --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.729 / Virus Database: 484 - Release Date: 27/07/2004
> I tried for several days to install the w32-postgres project. > Finally downloaded Powergres which is now running without > trouble on the HP notebook. From your post I think the > trouble is in the support ( lack of) for XP-Home. > I think there will be many with notbooks who would like to > use postgres as a development tool possibly with the view > that the final application will run on a XP/2000 or Linux server. We certainly hope to fix it for XP home. Truth is none of those of us who were working on it *knew* that the GUI wasn't there. But from what info I have, the API is still there, so once we integrate it in the installer it will be able to set those rights automatically on XP home as well. //Magnus
> I tried for several days to install the w32-postgres project. Finally > downloaded > Powergres which is now running without trouble on the HP notebook. From > your post I think the trouble is in the support ( lack of) for XP-Home. > I think there will be many with notbooks who would like to use postgres > as a development tool possibly with the view that the final application > will run on a XP/2000 or Linux server. > With all the hard work done and a great product nearly available it > would appear that the security issues are really hobbling the > finalisation of the w32 project. 1. XP home is not supported. XP home is not designed to run servers of any kind (PostgreSQL is a server). 2. Despite the above fact, that it's perfectly possible to run on XP home (except for as a service), you just have to know what you are doing. 3. PostgreSQL 7.5 is pre-beta. On any given day, the source might not compile/work. Since the dev period is about to close, there is some last minute rushing going on which have reduced the likelihood of things working of late. However, out of the last 3-4 months it worked fine out of the gate 80-90% of the time. 4. I've written a production application and done almost 6 months of development on with the port...it is stable, fast, and most likely the future of win32 development. Patience! Merlin
Richard Sydney-Smith wrote: > >From: Christian Klemke > > >Guys ! Please take into account that users will not be able to be run > the > >Postgres service on Win XP Home. XP Home does not offer the local > security > >policy editor and therefore it is not possible to have the > logon-as-service > >right for any user except administrators ......... > > I tried for several days to install the w32-postgres project. Finally > downloaded > Powergres which is now running without trouble on the HP notebook. From > your post I think the trouble is in the support ( lack of) for XP-Home. > I think there will be many with notbooks who would like to use postgres > as a development tool possibly with the view that the final application > will run on a XP/2000 or Linux server. > > With all the hard work done and a great product nearly available it > would appear that the security issues are really hobbling the > finalisation of the w32 project. Keep in mind we will be in beta for several months so we will get this all fixed by 7.5 final. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Thanks Merlin, Bruce and Magnus. The postgres conversion to windows is a mighty undertaking and one with significant impact. That said postgres has never been as easy to setup as most database systems! >From: Merlin Moncure [mailto:merlin.moncure@rcsonline.com] >1. XP home is not supported. XP home is not designed to run servers of any >kind (PostgreSQL is a server). Once postgres is available on windows machines I think it will used in a multitude of applications - some of which are directed towards single user situations. With the utmost respect I feel postgres needs to run without issues of the kind presently being presented. Further suggest that once the install is complete that the installer present the user with the option to run PGAdminIII so they can "see" their new database cluster in a modern user-friendly environment. For that matter can the installer add the localhost / username to PGAdminIII so that when it is opened for the first time their new server appears on the lefthandside. >2. Despite the above fact, that it's perfectly possible to run on XP home >(except for as a service), you just have to know what you are doing. Having the application start the postmaster if it is not running is always an option just a service seems the tidier solution and I would prefer to standardise and only run the application using the same method in all cases. >4. I've written a production application and done almost 6 months of >development on with the port...it is stable, fast, and most likely the future >of win32 development. I have also used postgres in an application I am eager to roll out. It is a great database. I just wish I had the time/skill to better understand. >Patience! Postgres is an awesome product and patience will be I'm sure its own reward in this situation. Sincerely Richard --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.729 / Virus Database: 484 - Release Date: 27/07/2004
I may have discovered a bug in the latest Win32 snapshots. I wanted to let you all know just in case this is not already being covered. If you need information like crash dumps, database schema, etc etc etc, let me know. I cannot run any trigger functions (pgplsql) that involve SELECT, INSERT, UPDATE or DELETE. The postgres backend that's handling the request crashes hard, though the main postmaster continues to run and handle requests. It happens regardless of the frontend (PGAdmin III, PHP) and it's consistent and reproducible. A simple trigger function like this crashes it: BEGIN SELECT NULL; END; One other note, triggers run fine on the 7.4 production running on FreeBSD, with the same data and database schema. -Keith Woodell System Administrator Natural Heritage New Mexico 505-277-3822 ext 232, 505-277-3844 (fax) Please report NHNM technical support issues at http://admin.heritage.unm.edu
> Once postgres is available on windows machines I think it will used in a > multitude of applications - some of which are directed towards single > user situations. With the utmost respect I feel postgres needs to run > without issues of the kind presently being presented. On this point I agree with you 100%. PostgreSQL has some features which make it ideal for packaging with an application. I used to work for a company that wrote GIS software which had heavy data requirements. At the time, tho, there was no viable win32 option, now there is. IMO, app + database installations should not install the full server. The application should open a pipe to postgres.exe. (the app could be installed with a pre-bootstrapped database). The problem of course is that means losing the libpq library. Thus, the long term solution is to have libpq/odbc/jdbc interface wrapper access to a standalone backend. These don't exist right now, but perhaps they might one day. In the mean time, we all have to work around this :( Merlin
"Merlin Moncure" <merlin.moncure@rcsonline.com> writes:
> I think the ultimate solution to this problem is to beef up the
> standalone backend functionality so that apps can just pipe to
> postgres.exe and not bother with the listening server (and security
> implications thereof).
This is actually on the to-do list (or at least my personal to-do list).
I had wanted it so that we could run "pg_dump -s" without a running
postmaster for pg_upgrade purposes. Bear in mind though that you'd only
get *one* database connection (no, you can't have multiple standalone
backends at once), so I'm not sure it would really be all that great
as a general-purpose application backend.
regards, tom lane
Merlin Moncure wrote: >>Once postgres is available on windows machines I think it will used in >> >> >a > > >>multitude of applications - some of which are directed towards single >>user situations. With the utmost respect I feel postgres needs to run >>without issues of the kind presently being presented. >> >> > >On this point I agree with you 100%. PostgreSQL has some features which >make it ideal for packaging with an application. I used to work for a >company that wrote GIS software which had heavy data requirements. At >the time, tho, there was no viable win32 option, now there is. > >IMO, app + database installations should not install the full server. >The application should open a pipe to postgres.exe. (the app could be >installed with a pre-bootstrapped database). The problem of course is >that means losing the libpq library. Thus, the long term solution is to >have libpq/odbc/jdbc interface wrapper access to a standalone backend. >These don't exist right now, but perhaps they might one day. In the >mean time, we all have to work around this :( > >Merlin > >---------------------------(end of broadcast)--------------------------- >TIP 6: Have you searched our list archives? > > http://archives.postgresql.org > > Agreed, while it would be very nice not to have to install the full server with a small single user app, a production state postgresql for windows is really needed, I have been using the beta for months now since way before pg_ctl was even working (i wrote a small c# app to stop and start postmaster and it into the background with no console window), the port has been coming along at such an awesome rate. All of you guys are doing an awesome job, and this will really change the face of windows sql development. Cos imo postgresql is the best sql database.
On 29.07.2004 08:29 Justin Wyer wrote: > All of you guys are doing an awesome job 150% ACK !!! > and this will really change the face of > windows sql development. Here I disagree. Most of the Windows (Desktop) users will be taken aback when beeing faced with the non-admin-account restriction and will happily switch over to a different database. But that has been discussed at full length already... Thomas