Re: Win32 PostgreSQL 8.0 Beta 1 Installer available for download
-----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 downloadI 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
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
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" <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 nameOK, 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
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:
Show quoted text
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 nameOK, 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 19073Hi,
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:
Show quoted text
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
I have applied the attached patch which adds get_home_path() which uses
USERPROFILE on Win32 and HOME on Unix.
This should fix the reported problem.
---------------------------------------------------------------------------
Andrew Dunstan wrote:
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
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" 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 19073Attachments:
/bjm/difftext/plainDownload+55-30
-----Original Message-----
From: pgsql-hackers-win32-owner@postgresql.org
[mailto:pgsql-hackers-win32-owner@postgresql.org] On Behalf
Of Bruce Momjian
Sent: 18 August 2004 03:59
To: Andrew Dunstan
Cc: Joerg Hessdoerfer; pgsql-hackers-win32@postgresql.org;
PostgreSQL-patches
Subject: Re: [pgsql-hackers-win32] 8.0 Beta 1 // Environment
Vars // .pgpassI have applied the attached patch which adds get_home_path()
which uses USERPROFILE on Win32 and HOME on Unix.This should fix the reported problem.
I now get the following error on Win32 following a make distclean:
fe-connect.o(.text+0x3428):fe-connect.c: undefined reference to
`get_home_path'
c:\mingw\bin\dllwrap.exe: c:\mingw\bin\gcc exited with status 1
make[3]: *** [libpq.a] Error 1
make[3]: Leaving directory `/cvs/pgsql/src/interfaces/libpq'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/cvs/pgsql/src/interfaces'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/cvs/pgsql/src'
make: *** [all] Error 2
:-(
Regards, Dave.
Import Notes
Resolved by subject fallback
Wow, that is strange. Did you do a 'make clean' before this? I don't
see why you would see the failure on Win32 and I don't see it on Unix.
Hold, we might have problems later on this for linking client apps
because as I remember win32 doesn't like the same symbol used in libpq
and pgport, but you haven't even gotten to that stage yet in the
compile. The workaround has been to make the function call a macro but
let's get libpq compiled first and see how it goes after that.
---------------------------------------------------------------------------
Dave Page wrote:
-----Original Message-----
From: pgsql-hackers-win32-owner@postgresql.org
[mailto:pgsql-hackers-win32-owner@postgresql.org] On Behalf
Of Bruce Momjian
Sent: 18 August 2004 03:59
To: Andrew Dunstan
Cc: Joerg Hessdoerfer; pgsql-hackers-win32@postgresql.org;
PostgreSQL-patches
Subject: Re: [pgsql-hackers-win32] 8.0 Beta 1 // Environment
Vars // .pgpassI have applied the attached patch which adds get_home_path()
which uses USERPROFILE on Win32 and HOME on Unix.This should fix the reported problem.
I now get the following error on Win32 following a make distclean:
fe-connect.o(.text+0x3428):fe-connect.c: undefined reference to
`get_home_path'
c:\mingw\bin\dllwrap.exe: c:\mingw\bin\gcc exited with status 1
make[3]: *** [libpq.a] Error 1
make[3]: Leaving directory `/cvs/pgsql/src/interfaces/libpq'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/cvs/pgsql/src/interfaces'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/cvs/pgsql/src'
make: *** [all] Error 2:-(
Regards, Dave.
--
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 19073I found the cause and just applied a fix. Thanks.
---------------------------------------------------------------------------
Bruce Momjian wrote:
Wow, that is strange. Did you do a 'make clean' before this? I don't
see why you would see the failure on Win32 and I don't see it on Unix.Hold, we might have problems later on this for linking client apps
because as I remember win32 doesn't like the same symbol used in libpq
and pgport, but you haven't even gotten to that stage yet in the
compile. The workaround has been to make the function call a macro but
let's get libpq compiled first and see how it goes after that.---------------------------------------------------------------------------
Dave Page wrote:
-----Original Message-----
From: pgsql-hackers-win32-owner@postgresql.org
[mailto:pgsql-hackers-win32-owner@postgresql.org] On Behalf
Of Bruce Momjian
Sent: 18 August 2004 03:59
To: Andrew Dunstan
Cc: Joerg Hessdoerfer; pgsql-hackers-win32@postgresql.org;
PostgreSQL-patches
Subject: Re: [pgsql-hackers-win32] 8.0 Beta 1 // Environment
Vars // .pgpassI have applied the attached patch which adds get_home_path()
which uses USERPROFILE on Win32 and HOME on Unix.This should fix the reported problem.
I now get the following error on Win32 following a make distclean:
fe-connect.o(.text+0x3428):fe-connect.c: undefined reference to
`get_home_path'
c:\mingw\bin\dllwrap.exe: c:\mingw\bin\gcc exited with status 1
make[3]: *** [libpq.a] Error 1
make[3]: Leaving directory `/cvs/pgsql/src/interfaces/libpq'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/cvs/pgsql/src/interfaces'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/cvs/pgsql/src'
make: *** [all] Error 2:-(
Regards, Dave.
-- 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---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
--
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