Обсуждение: registry vs. environment (was re:binary installer)

To all:

I think there are a couple of things about this issue that have not been
completely thought out.  Moving off of an environment based home
variable should not be taken lightly.  Switching the runtime environment
variables to use the registry will have several unintended consequences:

1. There are several warnings and messages in postgres that explicitly
make reference to environment variables...these now have to be changed
for the win32 port.

2. Application software written in C for PostgreSQL ported from unix may
not necessarily work anymore (assumptions about PGDATA).

3. Just like the registry, the env has a system and a user area to make
settings.  By default, mysql puts it home directory into the system
area.  Nobody on the mysql lists seems to have a problem with this.

4. Manipulating the environment is generally easier (either using SET or
parameter invocation from the command line) and has little/no win32
centric coding.

5. The PeerDirect port uses environment settings, and I found it easy to
work with...why fix something that isn't broken?

Regards,
Merlin

"Merlin Moncure" <merlin.moncure@rcsonline.com> writes:
> I think there are a couple of things about this issue that have not been
> completely thought out.  Moving off of an environment based home
> variable should not be taken lightly.  Switching the runtime environment
> variables to use the registry will have several unintended consequences:

I agree that we do not want to start hacking the parts of the code that
depend on environment variables.  A reasonable compromise would probably
be to have a small chunk of Windows-specific code at startup that reads
the registry and installs the values it finds there by doing putenv().
Thereafter everything operates the same as on Unix.

            regards, tom lane

Tom Lane wrote:
> I agree that we do not want to start hacking the parts of the code
that
> depend on environment variables.  A reasonable compromise would
probably
> be to have a small chunk of Windows-specific code at startup that
reads
> the registry and installs the values it finds there by doing putenv().
> Thereafter everything operates the same as on Unix.

putenv() in windows modifies the environment for the current process,
and any process that the process calling putenv creates (but not
globally).   As long as no 3rd party software relies on any env.
variables, then this is ok.

Merlin

"Merlin Moncure" <merlin.moncure@rcsonline.com> writes:
> putenv() in windows modifies the environment for the current process,
> and any process that the process calling putenv creates (but not
> globally).

This is the same as Unix.

            regards, tom lane

Tom Lane wrote:
> "Merlin Moncure" <merlin.moncure@rcsonline.com> writes:
> > I think there are a couple of things about this issue that have not been
> > completely thought out.  Moving off of an environment based home
> > variable should not be taken lightly.  Switching the runtime environment
> > variables to use the registry will have several unintended consequences:
>
> I agree that we do not want to start hacking the parts of the code that
> depend on environment variables.  A reasonable compromise would probably
> be to have a small chunk of Windows-specific code at startup that reads
> the registry and installs the values it finds there by doing putenv().
> Thereafter everything operates the same as on Unix.

Added to Win32 project page:

    <li>store setting in the registry and set environment
    variables in the process</li>

--
  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

Merlin Moncure wrote:
> To all:
>
> I think there are a couple of things about this issue that have not been
> completely thought out.  Moving off of an environment based home
> variable should not be taken lightly.  Switching the runtime environment
> variables to use the registry will have several unintended consequences:
>
> 1. There are several warnings and messages in postgres that explicitly
> make reference to environment variables...these now have to be changed
> for the win32 port.
>
> 2. Application software written in C for PostgreSQL ported from unix may
> not necessarily work anymore (assumptions about PGDATA).
>
> 3. Just like the registry, the env has a system and a user area to make
> settings.  By default, mysql puts it home directory into the system
> area.  Nobody on the mysql lists seems to have a problem with this.
>
> 4. Manipulating the environment is generally easier (either using SET or
> parameter invocation from the command line) and has little/no win32
> centric coding.
>
> 5. The PeerDirect port uses environment settings, and I found it easy to
> work with...why fix something that isn't broken?

The win32 TODO now has:

    Store settings in the registry and set environment variables in
    the process

What additional things to we need to deal with if we go the direction of
having the environment variables set from the registry and read-only in
the process?

--
  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

Bruce Momjian wrote:

>Merlin Moncure wrote:
>
>
>>To all:
>>
>>I think there are a couple of things about this issue that have not been
>>completely thought out.  Moving off of an environment based home
>>variable should not be taken lightly.  Switching the runtime environment
>>variables to use the registry will have several unintended consequences:
>>
>>1. There are several warnings and messages in postgres that explicitly
>>make reference to environment variables...these now have to be changed
>>for the win32 port.
>>
>>2. Application software written in C for PostgreSQL ported from unix may
>>not necessarily work anymore (assumptions about PGDATA).
>>
>>3. Just like the registry, the env has a system and a user area to make
>>settings.  By default, mysql puts it home directory into the system
>>area.  Nobody on the mysql lists seems to have a problem with this.
>>
>>4. Manipulating the environment is generally easier (either using SET or
>>parameter invocation from the command line) and has little/no win32
>>centric coding.
>>
>>5. The PeerDirect port uses environment settings, and I found it easy to
>>work with...why fix something that isn't broken?
>>
>>
>
>The win32 TODO now has:
>
>    Store settings in the registry and set environment variables in
>    the process
>
>What additional things to we need to deal with if we go the direction of
>having the environment variables set from the registry and read-only in
>the process?
>
>
>

I'm not clear *which* settings it is proposed to set in the registry,
nor how possible it will be to override the settings, and with which
mechanism.

The nicest things might be those things like paths that we currently set
at configure time - making postgres more easily relocatable would be a
Good Thing (tm).

We need to ensure that using the registry still allows us to run
multiple instances and multiple installations on the same machine easily.

cheers

andrew

Andrew Dunstan wrote:
> >The win32 TODO now has:
> >
> >    Store settings in the registry and set environment variables in
> >    the process
> >
> >What additional things to we need to deal with if we go the direction of
> >having the environment variables set from the registry and read-only in
> >the process?
> >
> >
> >
>
> I'm not clear *which* settings it is proposed to set in the registry,
> nor how possible it will be to override the settings, and with which
> mechanism.

I assumed all environment variables would be exported to the process.
The problem is allowing environment variables to override registry
settings.

One idea would be to do both --- if an environment variable isn't set,
get the value from the registry and set the envronment variable.  If the
environment variable is set, use that instead of the registry --- that
might be the best of both worlds.

> The nicest things might be those things like paths that we currently set
> at configure time - making postgres more easily relocatable would be a
> Good Thing (tm).
>
> We need to ensure that using the registry still allows us to run
> multiple instances and multiple installations on the same machine easily.

Yes, I think the above idea would work for that.

--
  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

Użytkownik Bruce Momjian wrote:

>I assumed all environment variables would be exported to the process.
>The problem is allowing environment variables to override registry
>settings.
>
>One idea would be to do both --- if an environment variable isn't set,
>get the value from the registry and set the envronment variable.  If the
>environment variable is set, use that instead of the registry --- that
>might be the best of both worlds.
>
>

Enviroment variables are stored in
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session
Manager\Environment.
There is no problem to look there if any variable is set or not and - to
add a registry key with new variable or to modify existing.


Rony

>> I think there are a couple of things about this issue that
>have not been
>> completely thought out.  Moving off of an environment based home
>> variable should not be taken lightly.  Switching the runtime
>environment
>> variables to use the registry will have several unintended
>consequences:
>>
>> 1. There are several warnings and messages in postgres that
>explicitly
>> make reference to environment variables...these now have to
>be changed
>> for the win32 port.

Or just a notice in the docs saying that the environment can be
populated from the registry, no? Since we'd still support environment
variables *as well*.


>> 2. Application software written in C for PostgreSQL ported
>from unix may
>> not necessarily work anymore (assumptions about PGDATA).

You mean application software that starts the postmaster on it's own? I
think those are going to have bigger problems than just environment
issues. If you mean things like user functions that *read* PGDATA, the
idea is still to set the variables from the data in the registry, so
there should be no difference for them (except if they puke on the
windows-style paths).

And client side environment handling should not be affected at all,
AFIAK.


>> 3. Just like the registry, the env has a system and a user
>area to make
>> settings.  By default, mysql puts it home directory into the system
>> area.  Nobody on the mysql lists seems to have a problem with this.

How have they solved the issue with multiple servers but only one system
area environment? You could change the names of the variables based on
instances, but that will be a lot more confusing, IMHO.


>> 4. Manipulating the environment is generally easier (either
>using SET or
>> parameter invocation from the command line) and has little/no win32
>> centric coding.

It is easier to manipulate *unless* you are running a service.
Manipulating the system-wide environment on win32 is not that easy. For
example, if you tweak it while running a command prompt, you have to
exit and restart the commandprompt for it to see the changes-.

AFAIK there has been no mention of removing the commandline parameter
passing. That would definitly be a bad idea.

It has no win32 centric coding, certainly.


>> 5. The PeerDirect port uses environment settings, and I
>found it easy to
>> work with...why fix something that isn't broken?

For a lot of windows admins, it will certainly be considered broken.
Win32 programs are generally not configured this way. Also, see above
issues about for example multiple instances.


>The win32 TODO now has:
>
>    Store settings in the registry and set environment variables in
>    the process
>
>What additional things to we need to deal with if we go the
>direction of
>having the environment variables set from the registry and read-only in
>the process?

I still beleive this way of doing things will be the best. If you want
it in the system environment, you can use that. If you put it in the
registry (service specific, for example), that will override those
settings and be used instead.

Depending on how services are implemented, this might not even need to
be inside the postmaster/postgres backend. If we chose to use an
external service wrapper (capable of dealing with our signals, still, so
it has to be pgsql-specific), we can have that one populate the
environment for the postmaster.


//Magnus

Magnus Hagander wrote:
> >What additional things to we need to deal with if we go the
> >direction of
> >having the environment variables set from the registry and read-only in
> >the process?
>
> I still beleive this way of doing things will be the best. If you want
> it in the system environment, you can use that. If you put it in the
> registry (service specific, for example), that will override those
> settings and be used instead.

I was thinking we can allow the environment to override the registry to
allow multiple postmasters.

--
  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

>> >What additional things to we need to deal with if we go the
>> >direction of
>> >having the environment variables set from the registry and
>read-only in
>> >the process?
>>
>> I still beleive this way of doing things will be the best.
>If you want
>> it in the system environment, you can use that. If you put it in the
>> registry (service specific, for example), that will override those
>> settings and be used instead.
>
>I was thinking we can allow the environment to override the registry to
>allow multiple postmasters.

But that will give you issues if you want multiple postmasters running
as services (different services, of course). Since you can't store the
environment variables in the system environment (because they would be
shared). The registry, however, is arranged with per-service areas to
store it in.

//Magnus

>
> Enviroment variables are stored in
> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session
> Manager\Environment.

There are system enviroment variables. For user enviroment variables see
HKEY_CURRENT_USER\Environment.
Windows API functions are SetEnvironmentVariable/GetEnvironmentVariable.
Both sets/gets the value of an environment variable for the current
process.



Rony