Some recent discussion on Stack Overflow has revealed another exciting
way for Windows computers to be subtly broken.
For as yet unknown reasons - probably related to security/virus scanner
software, since everything else seems to be - some Windows machines have
an invalid COMSPEC environment variable.
Two variants have been sighted in the wild:
(note the trailing semicolon), and:
Both will produce the delightfully helpful initdb failure:
initdb: could not execute command ""C:/Program
Files/PostgreSQL/9.2/bin/postgres.exe" --boot -x1 -F ": No error
cscript //NoLogo "C:\Program
AUTHORITY\NetworkService" "postgres" "****" "C:\Program
Files\PostgreSQL\9.2" "C:\Program Files\PostgreSQL\9.2\data" 5432 "DEFAULT"
which will exit with:
Script exit code: 1
In the one I was looking into, fixing COMSPEC in the System control
panel's Environment Variables page by removing the trailing semicolon
corrected the issue. It can be verified as correct by opening a new
command prompt after you've changed the variable (not just re-using an
existing already-open one) and running:
"%COMSPEC%" /C "echo test ok"
which should print:
not something like:
'"C:\Windows\System32\cmd.exe;"' is not recognized as an internal or
operable program or batch file."
Since I can find several reports of this spanning over a couple of
years, I'd love to see a test for this integrated into the EDB
installer. Just verify that popen() actually works before running the
initdb script, and if it doesn't, check %COMSPEC% to see if it really
points to cmd.exe .
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
pgsql-general by date
|Next:||From: Christian Jensen||Date: 2012-11-19 04:43:21|
|Subject: Full text search in Chinese|
|Previous:||From: Peter Geoghegan||Date: 2012-11-19 03:21:27|
|Subject: Re: Fuzzystrmatch contrib module on RHEL63|