Re: 8.0 Beta 1 // Environment Vars // .pgpass

> -----Original Message-----
> From: Aleksander Kmetec [mailto:aleksander(dot)kmetec(at)intera(dot)si]
> Sent: 10 August 2004 08:48
> To: Dave Page
> Cc: pgsql-hackers-win32(at)postgresql(dot)org;
> pginstaller-devel(at)pgfoundry(dot)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

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(at)vale-housing(dot)co(dot)uk> writes:
>> From: Aleksander Kmetec [mailto:aleksander(dot)kmetec(at)intera(dot)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

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(at)unm(dot)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(at)unm(dot)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(dot)hessdoerfer(at)sea-gmbh(dot)com
WWW: http://www.sea-gmbh.com

Joerg Hessdoerfer wrote:

>On Thursday 12 August 2004 06:25, Tom Lane wrote:
>
>
>>"efesar (the kay)" <efesar(at)unm(dot)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(at)postgresql(dot)org
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)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

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(at)unm(dot)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(at)postgresql(dot)org)
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073