I have been trying, without success, to get posgresql 9.3 up and running on Windows 8.1 on and off over the last ten days. Here is what I have done so far: I got the windows installer from enterprisedb and ran it. I got this message:

“there has been an error. Unable to write inside TEMP environment variable path.”

I bounced around the postgres docs and forums and eventually figured out that I needed to reset the file association for vbs, and when I did that, the install ran, but with two errors:

“warning. A non-fatal error occurred whilst loading database modules. Please check the error logs at …/appData\local\temp for details.”

This is because the admin module didn’t install

 “warning. Problem running post-install step. Installation may not complete correctly. Error reading file c:/program files/postgresql/9.3/data/postgresql.conf”

This is because there wasn’t a postgresql.conf file. I have to make it from the conf-sample provided. But when I went to create this file, I found out that’s not all I was missing. I also had to tell postgres where PGDATA is.
So how could I possibly avoid this error using the windows installer? It turns out, a default copy was supposed to be created for me.


Presumably, if that had worked, postgres would also know where PGDATA is. As it stands now, it thinks it is at C:/WINDOWS/system32/ It probably goes without saying to those of you with more experience, but repeated efforts to get postgres running as a service also failed, with the particularly unhelpful error message

“The postgres sql service started and then stopped. Some services stop automatically if they are not in use by other services or programs.”

Turns out from the event logs that I am getting the same error there, too. According to the postgres wiki,

“PostgreSQL for Windows installs the PGDATA directory by default into "C:\Program Files\PostgreSQL\some version\data". “

I have "C:\Program Files\PostgreSQL\9.3\bin\pg_ctl.exe" in the registry. Note this file does exist at that location.

I read on one of these places, I forget which one now, that my particular AV program is supposed to work without problems with postgres. Nevertheless, after repeated failures, I excluded the postgres directory from my AV scans anyway, but that did not improve things. I posted an earlier version of this question to the postgres mailing list but got no response.

My last two options were to try and name PGDATA from the command line using –D varname=value, but of course that didn’t work:

psql: could not connect to server: Connection refused (0x0000274D/10061)
        Is the server running on host "localhost" (::1) and accepting
        TCP/IP connections on port 5432?

Finally, I checked the ports. I say ‘finally’ because I didn’t think that was the issue since I had already opened Windows Firewall for postgres. It says postgres can access “any” port, which I would think means this should work, but if there is a way to edit it to specify port 5432, I didn’t see it.

With that background, here is my question:

Is this install hopelessly corrupted so that I should start over?

If so, what steps do you recommend to have it all go smoothly? Fixing the vbs issue did not prevent the failure of the admin module, PGDATA, or the conf. file, so what else should I do?

  • 1
    The install instructions, IIRC, ask you to disable any antivirus software before continuing. Disabling it after the fact won't help you much. I'd completely uninstall, delete the install directory after running the uninstaller, then disable the AV and re-try. There's no guarantee it's at fault, but it's certainly a strong suspect. Commented Mar 7, 2014 at 3:57
  • There's a known issue with address space layout randomization on Windows 8, btw. It will be worked around in PostgreSQL 9.3.4. In the mean time you can disable ASLR on the system if you encounter problems (you may not). Commented Mar 7, 2014 at 4:00


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Browse other questions tagged or ask your own question.