Обсуждение: Win32 PostgreSQL 8.0 Beta 1 Installer available for download
I've just packaged and uploaded a new version of the Win32 PostgreSQL installer beta, with PostgreSQL 8.0 Beta 1 and todays snapshot of pgAdmin III. This is a beta for the installer as well as PostgreSQL itself, so please report bugs for either. Bug reports for pgAdmin are also welcome at pgadmin-support@postgresql.org as we are nearing our own beta. This version of the installer includes various changes from the last version: - Add zlib.dll used by pg_dump et al. for compression - Warn the user that initdb may take a couple of minutes. - Allow user selection of service ID (allowing multiple postmaster services to be installed). - Write service details to a predicable location in the registry for use by control/client programs. - Set the default service account name to 'postgres' - Add missing encoding, sort the list. - Various spelling/layout cleanups. - pgAdmin now automatically detects local servers and allows startup/shutdown of them. Download from: http://pgfoundry.org/project/showfiles.php?group_id=1000007 Regards, Dave (and Magnus)
Dave Page wrote: > I've just packaged and uploaded a new version of the Win32 PostgreSQL > installer beta, with PostgreSQL 8.0 Beta 1 and todays snapshot of > pgAdmin III. This is a beta for the installer as well as PostgreSQL > itself, so please report bugs for either. I would like to report success on WinXP Pro SP1. It looks great, well done!!! > - Allow user selection of service ID (allowing multiple postmaster > services to be installed). Is it possible to install multiple instances from the installer? When I have installed the first instance and I execute the installer again it jumps to the last page and tells me installation is complete. > Download from: > http://pgfoundry.org/project/showfiles.php?group_id=1000007 This download could become quite popular after the news of Beta1 has hit pgsql-announce. It might be a good idea to set up a bittorrent tracker and / or use http://freecache.org/ when spreading the word. Jochem
I came across theese two problems while testing the installer: 1. Installer lists some database encodings which are not supported. Selecting win1250, for example, causes initdb to exit and the installation is then rolled back. initdb.log says: initdb: "WIN1250" is not a valid server encoding name 2. Uninstalling PG didn't remove the service. Instead, it just changed its startup type to "disabled". Other than that it seems to work great. I'm using windows 2000, sp4. Regards, Aleksander
Seems to work fine on WinXP SP1, Spanish version (handles "Archivos de Programa" and all that smoothly). pgAdmin III connects properly as well. Cheers, JP En/na Dave Page ha escrit: >I've just packaged and uploaded a new version of the Win32 PostgreSQL >installer beta, with PostgreSQL 8.0 Beta 1 and todays snapshot of >pgAdmin III. This is a beta for the installer as well as PostgreSQL >itself, so please report bugs for either. Bug reports for pgAdmin are >also welcome at pgadmin-support@postgresql.org as we are nearing our own >beta. > > -- JP Glutting Oficina de Qualitat Plaça Víctor Siurana, 1 Universitat de Lleida 25003 Lleida ------------------------------------------------------- Tel: 973 703 103 Fax: 973 702 036
> -----Original Message----- > From: Aleksander Kmetec [mailto:aleksander.kmetec@intera.si] > Sent: 10 August 2004 08:48 > To: Dave Page > Cc: pgsql-hackers-win32@postgresql.org; > pginstaller-devel@pgfoundry.org > Subject: Re: [pgsql-hackers-win32] Win32 PostgreSQL 8.0 Beta > 1 Installer available for download > > > I came across theese two problems while testing the installer: > > 1. Installer lists some database encodings which are not supported. > Selecting win1250, for example, causes initdb to exit and the > installation is then rolled back. > > initdb.log says: > initdb: "WIN1250" is not a valid server encoding name OK, it would seem that some of the encodings listed in src/backend/utils/mb/encnames.c are not listed as supported on http://developer.postgresql.org/docs/postgres/multibyte.html (that includes win1250). I have limited the list to exactly what's in the documentation. > > 2. Uninstalling PG didn't remove the service. Instead, it > just changed its startup type to "disabled". I cannot repeat that here on XP, however I have seen cases where the SCM simply disabled an uninstalled service and didn't actually remove it until sometime later. Could this be what happened in your case? Regards, Dave.
> > >>2. Uninstalling PG didn't remove the service. Instead, it >>just changed its startup type to "disabled". >> >> > >I cannot repeat that here on XP, however I have seen cases where the SCM >simply disabled an uninstalled service and didn't actually remove it >until sometime later. Could this be what happened in your case? > >Regards, Dave. > > When removing the service by hand using previous versions of Postgres, the service was not removed from the Services panel until I rebooted. This might be what is going on (WinXP here, though). Cheers, JP -- JP Glutting Oficina de Qualitat Plaça Víctor Siurana, 1 Universitat de Lleida 25003 Lleida ------------------------------------------------------- Tel: 973 703 103 Fax: 973 702 036
> -----Original Message----- > From: Johan Paul Glutting [mailto:jpglutting@vqp.udl.es] > Sent: 10 August 2004 09:25 > To: Dave Page > Cc: Aleksander Kmetec; pgsql-hackers-win32@postgresql.org; > pginstaller-devel@pgfoundry.org > Subject: Re: [pgsql-hackers-win32] Win32 PostgreSQL 8.0 Beta > 1 Installer available for download > > When removing the service by hand using previous versions of > Postgres, the service was not removed from the Services panel > until I rebooted. > This might be what is going on (WinXP here, though). Sounds like it - the SCM controls the actual removal of the service from the list - we just ask it to remove it for us. Regards, Dave.
Johan Paul Glutting wrote: > When removing the service by hand using previous versions of Postgres, > the service was not removed from the Services panel until I rebooted. > This might be what is going on (WinXP here, though). Yes; rebooting seems to take care of it. Did you try reinstalling PG without rebooting? On my machine it fails - unless I specify a different service ID. It took me a couple of installs to figure out that just changing the sevice NAME doesn't work, in which case everything runs fine until right after cluster creation, when you get an error message saying that the service couldn't be installed, followed by rollback. The solution could be to try and detect any existing services with the same ID and refuse to go to the next step if one already exists. Regards, Aleksander
Sorry Aleksander, but I can't really remember what I did. I had a service running from a Cygwin install of Postgres, and I was messing around with the command line for installing/uninstalling the service, and had to reboot several times. I initially tried to change the path of the sevice executable, and it was a big mess. This was the unzippable version of Postgres from about a moth ago, so it is not really relevant to this installer. As an aside, Dave, can we get the \bin and \lib paths in the PATH variable as part of the install? I am not sure if that will create a mess if they are already there ... Also, my PGDATA variable is still set at c:\postgres\data - but it does not seem to have an effect on Postgres. I am going to try accessing postgres with some python modules, and see what that does. Cheers, jp En/na Aleksander Kmetec ha escrit: > > Johan Paul Glutting wrote: > >> When removing the service by hand using previous versions of >> Postgres, the service was not removed from the Services panel until I >> rebooted. This might be what is going on (WinXP here, though). > > > Yes; rebooting seems to take care of it. > > Did you try reinstalling PG without rebooting? > On my machine it fails - unless I specify a different service ID. > > It took me a couple of installs to figure out that just changing the > sevice NAME doesn't work, in which case everything runs fine until > right after cluster creation, when you get an error message saying > that the service couldn't be installed, followed by rollback. > > The solution could be to try and detect any existing services with the > same ID and refuse to go to the next step if one already exists. > > Regards, > Aleksander -- JP Glutting Oficina de Qualitat Plaça Víctor Siurana, 1 Universitat de Lleida 25003 Lleida ------------------------------------------------------- Tel: 973 703 103 Fax: 973 702 036
> -----Original Message----- > From: Johan Paul Glutting [mailto:jpglutting@vqp.udl.es] > Sent: 10 August 2004 10:22 > To: Aleksander Kmetec > Cc: Dave Page; pgsql-hackers-win32@postgresql.org; > pginstaller-devel@pgfoundry.org > Subject: Re: [pgsql-hackers-win32] Win32 PostgreSQL 8.0 Beta > 1 Installer available for download > > Sorry Aleksander, but I can't really remember what I did. I > had a service running from a Cygwin install of Postgres, and > I was messing around with the command line for > installing/uninstalling the service, and had to reboot > several times. I initially tried to change the path of the > sevice executable, and it was a big mess. This was the > unzippable version of Postgres from about a moth ago, so it > is not really relevant to this installer. > > As an aside, Dave, can we get the \bin and \lib paths in the > PATH variable as part of the install? I am not sure if that > will create a mess if they are already there ... We're trying to avoid that to prevent problems with multiple installations on the same machine. All the shortcuts to psql, and backups/restores from pgAdmin should work fine without. > Also, my PGDATA variable is still set at c:\postgres\data - > but it does not seem to have an effect on Postgres. I am > going to try accessing postgres with some python modules, and > see what that does. The service is installed with the -D option to specify the data directory (iirc) which overrides any environment variables - again, this is to allow multiple installations in the future. Regards, Dave.
Responding to my own post, the ODBC module (from win32) works fine with python and Postgres. I couldn't get the others to work, but that is a problem with my system. Cheers, JP > > Also, my PGDATA variable is still set at c:\postgres\data - but it > does not seem to have an effect on Postgres. I am going to try > accessing postgres with some python modules, and see what that does. -- JP Glutting Oficina de Qualitat Plaça Víctor Siurana, 1 Universitat de Lleida 25003 Lleida ------------------------------------------------------- Tel: 973 703 103 Fax: 973 702 036
Dave Page wrote: > > We're trying to avoid that to prevent problems with multiple > installations on the same machine. All the shortcuts to psql, and > backups/restores from pgAdmin should work fine without. Restore is not done yet, coming RSN. Regards, Andreas
"Dave Page" <dpage@vale-housing.co.uk> writes: >> From: Aleksander Kmetec [mailto:aleksander.kmetec@intera.si] >> 1. Installer lists some database encodings which are not supported. > OK, it would seem that some of the encodings listed in > src/backend/utils/mb/encnames.c are not listed as supported on > http://developer.postgresql.org/docs/postgres/multibyte.html (that > includes win1250). I have limited the list to exactly what's in the > documentation. The point is that some of the encodings listed there are only supported on the client side, not inside the server. You should instead look to src/include/mb/pg_wchar.h, typedef pg_enc, and particularly PG_ENCODING_BE_LAST. regards, tom lane
Dave Page wrote: >>initdb.log says: >>initdb: "WIN1250" is not a valid server encoding name > > OK, it would seem that some of the encodings listed in > src/backend/utils/mb/encnames.c are not listed as supported on > http://developer.postgresql.org/docs/postgres/multibyte.html (that > includes win1250). I have limited the list to exactly what's in the > documentation. I've also noticed a problem with locales. Installer uses a static list of locales copied from MSDN. Because of this, not all locales installed on the current system are listed as available. Also, if you only supply a locale name to initdb, then the default encoding for that locale is used as value for lc_* settings (German_Germany.1252, Slovenian_Slovenia.1250, ...). This causes errors in sorting order and wrong return values for locale dependant functions when your database encoding differs from locale encoding. If there's nobody else working on this yet, I can try doing it myself, since I already have a piece of code which retrieves all installed locales and code pages for the current system. Regards, Aleksander
> -----Original Message----- > From: Aleksander Kmetec [mailto:aleksander.kmetec@intera.si] > Sent: 11 August 2004 05:00 > To: Dave Page > Cc: pgsql-hackers-win32@postgresql.org; > pginstaller-devel@pgfoundry.org > Subject: Re: [pgsql-hackers-win32] Win32 PostgreSQL 8.0 Beta > 1 Installer available for download > > Dave Page wrote: > >>initdb.log says: > >>initdb: "WIN1250" is not a valid server encoding name > > > > OK, it would seem that some of the encodings listed in > > src/backend/utils/mb/encnames.c are not listed as supported on > > http://developer.postgresql.org/docs/postgres/multibyte.html (that > > includes win1250). I have limited the list to exactly what's in the > > documentation. > > I've also noticed a problem with locales. > > Installer uses a static list of locales copied from MSDN. > Because of this, not all locales installed on the current > system are listed as available. Also, if you only supply a > locale name to initdb, then the default encoding for that > locale is used as value for lc_* settings > (German_Germany.1252, Slovenian_Slovenia.1250, ...). This > causes errors in sorting order and wrong return values for > locale dependant functions when your database encoding > differs from locale encoding. > > If there's nobody else working on this yet, I can try doing > it myself, since I already have a piece of code which > retrieves all installed locales and code pages for the current system. Please feel free to give it a go. Patches from anyone are welcome :-) Regards, Dave
The 8.0 version does not acknowledge env vars like PGPASSWORD and seems to ignore the contents of the .pgpass file. When there is not a c:\documents and settings\postgres\.pgpass the pg_restore program does not ask for a password but simply says this: G:\dbarchive>C:\Progra~1\PostgreSQL\8.0-beta1\bin\pg_restore -O -d blog -x -F c -h 127.0.0.1 -U postgres blogdb01 pg_restore: [archiver (db)] connection to database "blog" failed: FATAL: Password authentication failed for user "postgres" However when there is a .pgpass file, pg_restore asks for a password a la the -W switch but ignores the password in the .pgpass file. I realize the manual says the file will be ignored if it doesn't have the right permissions. In XP, I set the ONLY user (no inheritance) as postgres and gave it full read/write. I also set ownership to postgres. Still, it gets ignored. Ergo, I can't run any automated scripts for backing things up. Any suggestions? -kay www.fearstudios.com <http://www.fearstudios.com/> www.efesar.com <http://www.efesar.com/> www.efesar.com/blog <http://www.efesar.com/blog> www.burque.info <http://www.burque.info> --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.736 / Virus Database: 490 - Release Date: 8/9/2004
"efesar (the kay)" <efesar@unm.edu> writes:
> The 8.0 version does not acknowledge env vars like PGPASSWORD and seems to
> ignore the contents of the .pgpass file.
Hmmm. Those are probably the same problem, since finding .pgpass
depends on expanding the $HOME env var. But I have no idea why
env vars aren't working for you ...
regards, tom lane
Aleksander, Sorry to take so long to get back to you. I was able to re-install postgres without any problems (I had to eliminate the data directory by hand after the uninstall, or it would not initialize the new database). I am running WinXP, SP1. I checked the services before re-installing, and postgres was removed properly. Cheers, JP En/na Aleksander Kmetec ha escrit: > > Johan Paul Glutting wrote: > >> When removing the service by hand using previous versions of >> Postgres, the service was not removed from the Services panel until I >> rebooted. This might be what is going on (WinXP here, though). > > > Yes; rebooting seems to take care of it. > > Did you try reinstalling PG without rebooting? > On my machine it fails - unless I specify a different service ID. > > It took me a couple of installs to figure out that just changing the > sevice NAME doesn't work, in which case everything runs fine until > right after cluster creation, when you get an error message saying > that the service couldn't be installed, followed by rollback. > > The solution could be to try and detect any existing services with the > same ID and refuse to go to the next step if one already exists. > > Regards, > Aleksander >
On Thursday 12 August 2004 06:25, Tom Lane wrote:
> "efesar (the kay)" <efesar@unm.edu> writes:
> > The 8.0 version does not acknowledge env vars like PGPASSWORD and seems
> > to ignore the contents of the .pgpass file.
>
> Hmmm. Those are probably the same problem, since finding .pgpass
> depends on expanding the $HOME env var. But I have no idea why
> env vars aren't working for you ...
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend
Yep. AFAIK, $HOME doesn't always exist in WIN32, but $HOMEDRIVE and $HOMEPATH
(or %HOMEPATH% and %HOMEDRIVE% ;-) do. Perhaps PG needs to do some munging to
build the home path from those two?
Greetings,
Joerg
--
Leading SW developer - S.E.A GmbH
Mail: joerg.hessdoerfer@sea-gmbh.com
WWW: http://www.sea-gmbh.com
Joerg Hessdoerfer wrote: >On Thursday 12 August 2004 06:25, Tom Lane wrote: > > >>"efesar (the kay)" <efesar@unm.edu> writes: >> >> >>>The 8.0 version does not acknowledge env vars like PGPASSWORD and seems >>>to ignore the contents of the .pgpass file. >>> >>> >>Hmmm. Those are probably the same problem, since finding .pgpass >>depends on expanding the $HOME env var. But I have no idea why >>env vars aren't working for you ... >> >> >Yep. AFAIK, $HOME doesn't always exist in WIN32, but $HOMEDRIVE and $HOMEPATH >(or %HOMEPATH% and %HOMEDRIVE% ;-) do. Perhaps PG needs to do some munging to >build the home path from those two? > > > > On my XP-Pro machine the appropriate setting appears to be %USERPROFILE% - %HOMEPATH% is just "\" See here for a complete list of available environment vars: http://www.winnetmag.com/Article/ArticleID/23873/23873.html cheers andrew
Added to open list:
o allow installed encodings and locales rather than just
hardcoded ones
and
o update encoding list to include win1250
o synchonize supported encodings and docs
---------------------------------------------------------------------------
Aleksander Kmetec wrote:
> Dave Page wrote:
> >>initdb.log says:
> >>initdb: "WIN1250" is not a valid server encoding name
> >
> > OK, it would seem that some of the encodings listed in
> > src/backend/utils/mb/encnames.c are not listed as supported on
> > http://developer.postgresql.org/docs/postgres/multibyte.html (that
> > includes win1250). I have limited the list to exactly what's in the
> > documentation.
>
> I've also noticed a problem with locales.
>
> Installer uses a static list of locales copied from MSDN. Because of
> this, not all locales installed on the current system are listed as
> available. Also, if you only supply a locale name to initdb, then the
> default encoding for that locale is used as value for lc_* settings
> (German_Germany.1252, Slovenian_Slovenia.1250, ...). This causes errors
> in sorting order and wrong return values for locale dependant functions
> when your database encoding differs from locale encoding.
>
> If there's nobody else working on this yet, I can try doing it myself,
> since I already have a piece of code which retrieves all installed
> locales and code pages for the current system.
>
> Regards, Aleksander
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
>
--
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
Hi, I think I finally have this narrowed down to a reproducible scenario. Reproducible on my machine, at least. :-) - If you install with default service ID (pgsql-8.0-beta1) and the service is started when you run uninstall, then it is removed immediately. - If you install with default service ID (pgsql-8.0-beta1) and the service is stopped, then it is marked as disabled and removed at first reboot. - If you use a custom service ID, then it is never removed and you have to use a registry editor to delete it manually. Regards, Aleksander Johan Paul Glutting wrote: > Aleksander, > > Sorry to take so long to get back to you. > I was able to re-install postgres without any problems (I had to > eliminate the data directory by hand after the uninstall, or it would > not initialize the new database). > I am running WinXP, SP1. I checked the services before re-installing, > and postgres was removed properly. > > Cheers, > > JP