Обсуждение: 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-specificapplication data folder (f.e., C:\PostgreSQL\8.4\data). It results in some unexpected bugs. There wereno such effects in Win XP and 2000. Has anyone fixed something similar to the described situation? Is it possible to improve it? Regards, Marina.
> -----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-specificapplication data folder (f.e., C:\PostgreSQL\8.4\data). It results in some unexpected bugs. There wereno 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-specificapplication data folder (f.e., C:\PostgreSQL\8.4\data). It results in some unexpected bugs. There
wereno 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, butgot an error "Could not open relation base\16123\16222: No such file or directory". Later I found out, using 'ProcessMonitor', 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 tomake test and install it from Installer I got the same result. :( "Data Directory" was set to PG-specific application dir. 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, butgot an error "Could not open relation base\16123\16222: No such file or directory". Later I found out, using 'ProcessMonitor', 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 triedto make test and install it from Installer I got the same result. :( "Data Directory" was set to PG-specific applicationdir. 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
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 putmy data in some definite location and postgres looks for it in another one - that's the strangeness of situation for me. Regards, Marina. > It is a vexed issue with Vista/Windows 7. > I found this somewhere on a blog on the web (it may help): > > Regards > Andrew
> -----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, butgot an error "Could not open relation base\16123\16222: No such file or directory". Later I found out, using 'ProcessMonitor', 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 triedto make test and install it from Installer I got the same result. :( "Data Directory" was set to PG-specific applicationdir. > > 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/ ___________________________________________