Re[2]: [GENERAL] 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\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. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Problems with Vista and Windows 7
2010/7/8 el dorado do_ra...@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
Re[2]: [GENERAL] Problems with Vista and Windows 7
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. It is a vexed issue with Vista/Windows 7. I found this somewhere on a blog on the web (it may help): Regards Andrew -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Problems with Vista and Windows 7
-Original Message- From: el dorado [mailto:do_ra...@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 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Problems with Vista and Windows 7
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 dp...@pgadmin.org wrote: 2010/7/8 el dorado do_ra...@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/ ___ -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] 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. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Problems with Vista and Windows 7
-Original Message- From: el dorado [mailto:do_ra...@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 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Problems with Vista and Windows 7
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
Re: [GENERAL] Problems with Vista and Windows 7
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 cr...@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/ ___ -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Problems with Vista and Windows 7
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 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
