Summary
A PostgreSQL installation on Windows failed immediately with a getlocales.ps1 “path not found” error, even though C:\Temp existed and permissions were correct. The failure stemmed from how the installer dynamically extracts and invokes PowerShell scripts in temporary directories, combined with Windows path‑resolution inconsistencies.
Root Cause
The underlying issue was triggered by PowerShell being invoked with a path that Windows could not resolve, typically due to one of the following conditions:
- Installer extracting scripts into a non-existent or incorrectly resolved temp directory
- Windows path canonicalization issues when running PowerShell from
System32under certain elevation contexts - ExecutionPolicy or PowerShell subsystem inconsistencies causing the script to fail before the path is validated
- Winget/EDB installer using a hardcoded or malformed temp path, often involving:
- Unicode characters in the user profile
- Spaces or quoting issues
- Redirected TEMP/TMP variables
- Windows 11 virtualization or filesystem redirection interfering with script execution
Why This Happens in Real Systems
This class of failure is common in Windows-based installers because:
- Installers often assume TEMP/TMP behave consistently, but Windows can redirect them depending on:
- Admin elevation
- UAC virtualization
- System32 vs SysWOW64 execution
- PowerShell scripts inside installers are extracted at runtime, meaning:
- The path must exist
- The path must be accessible to the elevated process
- The path must be resolvable by PowerShell’s internal path parser
- Windows 11 tightened security around script execution, causing silent failures when:
- ExecutionPolicy is bypassed incorrectly
- Script paths contain characters PowerShell cannot parse
Real-World Impact
When this failure occurs, users experience:
- Complete installer failure before PostgreSQL even begins setup
- Misleading error messages that imply the folder is missing when the real issue is path resolution
- Inability to install PostgreSQL via EDB or Winget
- Blocked development environments, especially for:
- Data engineers
- Backend developers
- Students using PostgreSQL for coursework
Example or Code (if necessary and relevant)
Below is a minimal PowerShell snippet that reproduces the same class of failure when Windows cannot resolve a quoted path:
powershell.exe -ExecutionPolicy Bypass -File "C:\Temp\folder that\does not\exist\script.ps1"This fails with the same “system cannot find the path specified” error even if the parent directory exists.
How Senior Engineers Fix It
Experienced engineers approach this by validating the entire execution chain, not just the folder:
- Verify actual runtime TEMP/TMP used by the elevated installer:
- Run PowerShell as admin and check:
echo $env:TEMP echo $env:TMP
- Run PowerShell as admin and check:
- Force-create the exact directory the installer expects, not just
C:\Temp - Temporarily override TEMP/TMP to a known-good path:
- Set both system and user TEMP/TMP to
C:\Temp
- Set both system and user TEMP/TMP to
- Reinstall PowerShell components if path resolution is broken
- Run the installer from a non-Unicode, non-spaced path
- Avoid Winget for PostgreSQL when script extraction fails; use the ZIP or EDB offline installer instead
Why Juniors Miss It
Less experienced engineers often focus on the visible folder rather than the execution context, leading them to miss:
- That TEMP/TMP differ between admin and non-admin shells
- That PowerShell path parsing breaks silently when quoting is wrong
- That installers extract scripts dynamically, so the path in the error message may not reflect the real failure
- That Windows 11’s security model can block script execution without clear logs
- That Winget installers wrap multiple layers of execution, making the error misleading
Juniors tend to fix the symptom (“create C:\Temp”) instead of diagnosing the underlying PowerShell invocation environment, which is where the real failure occurs.