Problems with Vista and Windows 7

-----Original Message-----
From: el dorado [mailto:do_ra_do@mail.ru]
Sent: Wednesday, July 07, 2010 4:19 AM
To: pgsql-general@postgresql.org
Subject: Problems with Vista and Windows 7

Hello!
I use Postgres 8.4.1 as service, with Windows 7. It seems to
me the same situation will take place with Vista.

I've notice that in some special cases PG uses folder
%APPDATA% for Windows user 'postgres', instead of the
PostgreSQL-specific application data folder (f.e.,
C:\PostgreSQL\8.4\data). It results in some unexpected bugs.
There were no such effects in Win XP and 2000.

Has anyone fixed something similar to the described
situation? Is it possible to improve it?

Regards, Marina.

Could you please be more specific in describing what problems are you
seeing on Win7?
Did you check, that registry key "Data Directory" is set properly in
"HKEY_LOCAL_MACHINE\SOFTWARE\PostgreSQL\Installations\postgresql-8.4"
folder?

Regards,
Igor Neyman

On 07/07/10 16:19, el dorado wrote:

Hello!
I use Postgres 8.4.1 as service, with Windows 7. It seems to me the same situation will take place with Vista.

I've notice that in some special cases PG uses folder %APPDATA% for Windows user 'postgres', instead of the PostgreSQL-specific application data folder (f.e., C:\PostgreSQL\8.4\data). It results in some unexpected bugs. There were no such effects in Win XP and 2000.

What files are being created in %APPDATA% for the postgres user? Or
what's it looking for there that's causing issues?

--
Craig Ringer

It is a vexed issue with Vista/Windows 7.

I found this somewhere on a blog on the web (it may help):

--------------------------
When I'm working to resolve compatibility issues, there are always
multiple options to mitigate. The solution we prefer to use is to update
the code.

A common application code update is this: "my application used to write
files to program files. It felt like as good a place to put it as any
other. It had my application's name on it already, and because my users
were admins, it worked fine. But now I see that this may not be as great
a place to stick things as I once thought, because with UAC even
Administrators run with standard user-like privileges most of the time.
So, where should I put my files instead?"

The answer, as it turns out, is: it depends.

Let's look at the options, and when you might want to choose each.

First, you'll want to use the SHGetKnownFolderPath API function to pull
the function if you are using native code. If you are using managed
code, System.Environment.GetFolderPath will do the trick for you.

FOLDERID_ProgramData /
System.Environment.SpecialFolder.CommonApplicationData
The user would never want to browse here in Explorer, and settings
changed here should affect every user on the machine. The default
location is %systemdrive%\ProgramData, which is a hidden folder, on an
installation of Windows Vista. You'll want to create your directory and
set the ACLs you need at install time.

FOLDERID_Public / FOLDERID_PublicDocuments /
System.Environment.GetEnvironmentVariable("public")
The user would want to browse here in Explorer and double click to open
the file. The default location is %public%, which has explicit links
throughout Explorer, on an installation of Windows Vista. You'll want to
create your directory and set the ACLs you need at install time.

FOLDERID_RoamingAppData /
System.Environment.SpecialFolder.ApplicationData
The user would never want to browse here in Explorer, and settings
changed here should roam with the user. The default location is %appdata
%, which is a hidden folder, on an installation of Windows Vista.

FOLDERID_LocalAppData /
System.Environment.SpecialFolder.LocalApplicationData
The user would never want to browse here in Explorer, and settings
changed here should stay local to the computer. The default location is
%localappdata%, which is a hidden folder, on an installation of Windows
Vista.

FOLDERID_Documents / System.Environment.SpecialFolder.MyDocuments
The user would want to browse here in Explorer and double click to open
the file. The default location is %userprofile%\documents, which has
explicit links throughout Explorer, on an installation of Windows Vista.

Now, you'll note that FOLDERID_Public is kind of the oddball here.
System.Environment.GetFolderPath just calls SHGetFolderPath, which takes
CSIDLs. There is no analogue for %public% here. However, we could have
gone after CSIDL_COMMON_DOCUMENTS (FOLDERID_PublicDocuments) and dropped
things there, but even though we just need to pass 0x2e (46) as the int
argument, we don't offer that. Because we have this subset going, I'd
probably start thinking about using p/invoke if I needed to support
public documents
(http://www.pinvoke.net/default.aspx/shell32.SHGetKnownFolderPath).

----------------

Regards
Andrew

2010/7/8 Craig Ringer <craig@postnewspapers.com.au>:

On 07/07/10 16:19, el dorado wrote:

Hello!
I use Postgres 8.4.1 as service, with Windows 7. It seems to me the same situation will take place with Vista.

I've notice that in some special cases PG uses folder %APPDATA% for Windows user 'postgres', instead of the PostgreSQL-specific application data folder (f.e., C:\PostgreSQL\8.4\data). It results in some unexpected bugs. There were no such effects in Win XP and 2000.

What files are being created in %APPDATA% for the postgres user? Or
what's it looking for there that's causing issues?

--
Craig Ringer

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

--
___________________________________________
Andrew J. P. Maclean
Centre for Autonomous Systems
The Rose Street Building J04
The University of Sydney 2006 NSW
AUSTRALIA
Ph: +61 2 9351 3283
Fax: +61 2 9351 7474
URL: http://www.acfr.usyd.edu.au/
___________________________________________

On 08/07/10 09:22, Andrew Maclean wrote:

It is a vexed issue with Vista/Windows 7.

I found this somewhere on a blog on the web (it may help):

The default datadir location has been discussed to death. There are
fairly decent reasons it's still in Program Files on Vista/Win7 - not
the least of which is "that's where Microsoft SQL Server puts it".

--
Craig Ringer

I've notice that in some special cases PG uses folder
%APPDATA% for Windows user 'postgres', instead of the
PostgreSQL-specific application data folder (f.e.,
C:\PostgreSQL\8.4\data). It results in some unexpected bugs.

Could you please be more specific in describing what problems are you
seeing on Win7?
Regards, Igor Neyman

What files are being created in %APPDATA% for the postgres user? Or
what's it looking for there that's causing issues?
Craig Ringer

Thank you for your answers.
Well, the beginning of the story in details is here (http://archives.postgresql.org/pgsql-general/2010-06/msg01135.php). Shortly, I tried to use functions from my own dll, but got an error "Could not open relation base\16123\16222: No such file or directory". Later I found out, using 'Process Monitor', that for some reason process 'postgres.exe' looked for this relation not in 'C:\PostgreSQL\8.4\data\base\16123\16222' but in 'C:\Users\postgres\AppData\Roaming\MyApplicationName\base\16123\16222' - certainly, there is no such file.

Did you check, that registry key "Data Directory" is set properly in
"HKEY_LOCAL_MACHINE\SOFTWARE\PostgreSQL\Installations\postgresql-8.4"
folder?

Usually I don't use standard Windows Installer but take binaries. So there is no such branch in registry. When I tried to make test and install it from Installer I got the same result. :( "Data Directory" was set to PG-specific application dir.

Regards, Marina.

Thank you, Andrew, it's very interesting and cognitive article.
Though it couldn't resolve my problem now. It looks like recommendations - where to put your application data. But I put my data in some definite location and postgres looks for it in another one - that's the strangeness of situation for me.

Regards, Marina.

2010/7/8 el dorado <do_ra_do@mail.ru>:

Thank you for your answers.
Well, the beginning of the story in details is here (http://archives.postgresql.org/pgsql-general/2010-06/msg01135.php). Shortly, I tried to use functions from my own dll, but got an error "Could not open relation base\16123\16222: No such file or directory". Later I found out, using 'Process Monitor', that for some reason process 'postgres.exe' looked for this relation not in 'C:\PostgreSQL\8.4\data\base\16123\16222' but in 'C:\Users\postgres\AppData\Roaming\MyApplicationName\base\16123\16222' - certainly, there is no such file.

Did you check, that registry key "Data Directory" is set properly in
"HKEY_LOCAL_MACHINE\SOFTWARE\PostgreSQL\Installations\postgresql-8.4"
folder?

Usually I don't use standard Windows Installer but take binaries. So there is no such branch in registry. When I tried to make test and install it from Installer I got the same result. :( "Data Directory" was set to PG-specific application dir.

So this is an issue with an extension of your own? Can you post the code?

You'll have to excuse us being skeptical about PostgreSQL being
fundamentally broken in the way you describe. The Windows installer
alone is downloaded tens of thousands of times per week, so I'm pretty
sure someone would have reported such an issue before now. And that's
ignoring the vast amount of testing that goes into every release,
including on 32 and 64 bit versions of XP through 7 and 2003 through
2008R2.

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise Postgres Company

-----Original Message-----
From: el dorado [mailto:do_ra_do@mail.ru]
Sent: Thursday, July 08, 2010 3:47 AM
To: pgsql-general@postgresql.org
Subject: Re[2]: Problems with Vista and Windows 7

I've notice that in some special cases PG uses folder

%APPDATA% for

Windows user 'postgres', instead of the PostgreSQL-specific
application data folder (f.e., C:\PostgreSQL\8.4\data).

It results

in some unexpected bugs.

Could you please be more specific in describing what

problems are you

seeing on Win7?
Regards, Igor Neyman

What files are being created in %APPDATA% for the postgres user? Or
what's it looking for there that's causing issues?
Craig Ringer

Thank you for your answers.
Well, the beginning of the story in details is here
(http://archives.postgresql.org/pgsql-general/2010-06/msg01135
.php). Shortly, I tried to use functions from my own dll, but
got an error "Could not open relation base\16123\16222: No
such file or directory". Later I found out, using 'Process
Monitor', that for some reason process 'postgres.exe' looked
for this relation not in
'C:\PostgreSQL\8.4\data\base\16123\16222' but in
'C:\Users\postgres\AppData\Roaming\MyApplicationName\base\1612
3\16222' - certainly, there is no such file.

Did you check, that registry key "Data Directory" is set

properly in

"HKEY_LOCAL_MACHINE\SOFTWARE\PostgreSQL\Installations\postgresql-8.4"

folder?

Usually I don't use standard Windows Installer but take
binaries. So there is no such branch in registry. When I
tried to make test and install it from Installer I got the
same result. :( "Data Directory" was set to PG-specific
application dir.

Regards, Marina.

So, if you just use binaries (no registry entries created), could you
try to set PGDATA environment variable, and see if this helps?

Regards,
Igor Neyman

I should add that I have no problems running Postgres in Windows 7.
The Windows installer works Ok for me.
In this thread I am not clear about whether it is postgres data (data
written and read by PostgreSQL) or user data that is being discussed.

Regards
Andrew

On Thu, Jul 8, 2010 at 5:53 PM, Dave Page <dpage@pgadmin.org> wrote:

2010/7/8 el dorado <do_ra_do@mail.ru>:

Thank you for your answers.
Well, the beginning of the story in details is here (http://archives.postgresql.org/pgsql-general/2010-06/msg01135.php). Shortly, I tried to use functions from my own dll, but got an error "Could not open relation base\16123\16222: No such file or directory". Later I found out, using 'Process Monitor', that for some reason process 'postgres.exe' looked for this relation not in 'C:\PostgreSQL\8.4\data\base\16123\16222' but in 'C:\Users\postgres\AppData\Roaming\MyApplicationName\base\16123\16222' - certainly, there is no such file.

Did you check, that registry key "Data Directory" is set properly in
"HKEY_LOCAL_MACHINE\SOFTWARE\PostgreSQL\Installations\postgresql-8.4"
folder?

Usually I don't use standard Windows Installer but take binaries. So there is no such branch in registry. When I tried to make test and install it from Installer I got the same result. :( "Data Directory" was set to PG-specific application dir.

So this is an issue with an extension of your own? Can you post the code?

You'll have to excuse us being skeptical about PostgreSQL being
fundamentally broken in the way you describe. The Windows installer
alone is downloaded tens of thousands of times per week, so I'm pretty
sure someone would have reported such an issue before now. And that's
ignoring the vast amount of testing that goes into every release,
including on 32 and 64 bit versions of XP through 7 and 2003 through
2008R2.

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise Postgres Company

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

--
___________________________________________
Andrew J. P. Maclean
Centre for Autonomous Systems
The Rose Street Building J04
The University of Sydney 2006 NSW
AUSTRALIA
Ph: +61 2 9351 3283
Fax: +61 2 9351 7474
URL: http://www.acfr.usyd.edu.au/
___________________________________________