Skip to content
Scripts to build PostgreSQL and its dependencies on Windows automatically
Perl PowerShell Shell
Find file
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Failed to load latest commit information.

These scripts create a PostgreSQL build environment for Windows, and build PostgreSQL.

The scripts use Perl as a wrapper around Microsoft's nmake, the build tool that comes with the Microsoft Windows SDK and with Visual Studio.

You will need installs of ActiveState Perl, ActiveState TCL, Python 2, MinGW, git (from, and the Microsoft SDK 7.1 to use these scripts. If you want to use a different Windows SDK, see "Other SDKs".

I recommend that you avoid running these scripts on a machine you use to run a real PostgreSQL instance you care about. These scripts won't break anything (that I'm aware of), but on Windows it's generally risky to do dev work on a production machine. As always, keep good backups and make a restore point before proceeding.

Download Windows SDK 7.1

You can download the SDK from: (web installer) or (offline installers ISOs).

If using the offline installer, get GRMSDKX_EN_DVD.iso for x64 or GRMSDK_EN_DVD.iso for x86. You don't need to burn a CD to install it, see below for instructions.

You must already have .NET 4 client profile installed to be able to run the Windows SDK offline installer. It's installed by default on Windows 7 and Win2k8 R2 but must be installed manually for older platforms. Get it here:

If you have Visual Studio 2010 redistributible packages installed or have version 2010 or 2012 of Visual Studio installed, additional steps are required to install the Windows SDK 7.1 correctly. See TROUBLESHOOTING.

Download required tools

Some of this will be automated later, but for now you must download the following required tools. Don't install them; see below for that.

All these instructions assume you're on a 64-bit windows install. If you're on 32-bit, don't bother downloading the 64-bit installers and omit all steps that refer to them. These instructions and scripts are NOT TESTED on 32-bit windows, only on 64-bit Windows 7 and Windows Server 2008 R2.


... and optionally:

You need MinGW even for MSVC builds because you need the "flex" executable from it to build on x64; the version provided on the PostgreSQL site doesn't run on win64. These scripts also use bison, wget and touch from mingw. All these tools come with msysgit too, so a future version may support using msysgit instead of MinGW.

I also recommend:

Install the tools

Open a command prompt and cd to the location you downloaded all the above tools to.

Now use the following commands to install the tools. On Windows the command prompt doesn't wait until a spawned command completes; you can use "start /WAIT" to launch them and wait, but it won't work with all installers.

You will need to adjust the file names to reflect the exact files you downloaded.

If you're on a 32-bit platform, omit the lines for 64-bit programs and for Perl, use PERL_PATH=Yes PERL_EXT=Yes for the 32-bit version since you aren't installing the 64-bit version.

start /wait mingw-get-inst-20120426.exe /silent
c:\MinGW\bin\mingw-get.exe install msys-flex msys-bison g++ gdb mingw32-make msys-base
start /wait msiexec /i 7z920-x64.msi /qb /passive /norestart
start /wait Git-1.8.0-preview20121022.exe /silent
start /wait msiexec /i ActivePerl- /qb /passive PERL_PATH=Yes PERL_EXT=Yes
start /wait msiexec /i ActivePerl- /qb /passive PERL_PATH=No PERL_EXT=No
start /wait msiexec /i python-2.7.3.amd64.msi /qb /passive TARGETDIR=%SystemDrive%\Python27_x64 ALLUSERS=1
start /wait msiexec /i python-2.7.3.msi /qb /passive TARGETDIR=%SystemDrive%\Python27_x86 ALLUSERS=1
start /wait msiexec /i python-3.3.0.amd64.msi /qb /passive TARGETDIR=%SystemDrive%\Python33_x64 ALLUSERS=1
start /wait msiexec /i python-3.3.0.msi /qb /passive TARGETDIR=%SystemDrive%\Python33_x64 ALLUSERS=1

Now install TCL if you want it. These installers don't run fully unattended. start /wait ActiveTcl8.5.-win32-ix86-threaded.exe --directory %SystemDrive%\TCL_85_x86 start /wait ActiveTcl8.5.-win32-x86_64-threaded.exe --directory %SystemDrive%\TCL_85_x64

If you downloaded the offline install ISO for the Windows SDK, you can install it with:

"%PROGRAMFILES%\7-Zip\7z.exe" x -owinsdk GRMSDKX_EN_DVD.iso
start /wait winsdk\setup.exe -q -params:ADDLOCAL=ALL
rd /s /q winsdk

(Change GRMSDKX_EN_DVD.iso to GRMSDK_EN_DVD.iso if you're on x64)

Optionally also install notepad++:

start /wait npp.6.2.2.Installer.exe /S

Configure the build

Copy to and edit it to reflect your environment. You can pass the settings on the command line instead, but currently an empty is still required.

Settings on the command line are passed as nmake variables, eg:

SETTING="the value"

and in as Perl hashmap entries, eg:

'SETTING' => 'the value',

To see what you can override, see the settings summary printed when you run /, or examine PgBuildWin\ .

There are two build modes offered; you must pick whether you want the build scripts to manage the PostgreSQL sources trees for you by checking them out from git, or whether you want to manage them yourself. These modes do not affect libraries, only management of the PostgreSQL sources.

In either case, you must set LIBDIR to the absolute path you want to put the dependencies that the build scripts manage for you, eg:


Anything inside LIBDIR will be deleted by "build{git|cwd}.pl really-clean"

Automatic PostgreSQL source trees -

If you use specify where to put the source trees (PGDIR), where to find a PostgreSQL git mirror (PG_GIT_URL), what branch to check out (PG_BRANCH) and optionally the location of the git executable (GIT), the build scripts will manage your builds for you under PGDIR. Eg, in

'GIT' => 'c:\Program Files (x86)\Git\bin\git.exe',
'PGDIR' => 'c:\postgresql-build',
'PG_GIT_URL' => 'c:\postgresql-git-bare-mirror',
'PG_BRANCH' => 'master'

Anything inside PGDIR will be deleted by " really-clean". The source tree will be reset using "git clean -fdx" when you " clean" or " postgresql-clean", so don't do work in the script-managed PostgreSQL trees; either push to a branch and have the tools build the branch, or manually manage the source tree (see below).

Builds and installs will go in different locations (PGBUILDDIR) based on their settings

  • /x86 vs /x64, /release vs /debug, SDK version, target OS, and Pg branch. For example, REL9_2_STABLE built for /x86 /release /xp built with Windows SDK 7.1 with PGDIR set to c:\postgresql-build will go in:


As cloning Pg from scratch takes time and bandwidth, I recommend cloning a bare copy of the Pg repo outside LIBDIR and PGDIR, eg:

git clone --bare --mirror git:// d:/postgresql-git

and specifying the path to it as PG_GIT_URL:

'PG_GIT_URL' => 'd:\postgresql-git'

To pull new changes into that repository use, "git fetch".

Manually managed PostgreSQL source trees - set PGBUILDDIR

If you're developing PostgreSQL in an existing working tree or you're using these scripts for a buildfarm / continuous integration setup, you or some other tools might be managing your git checkouts, or you could even be working from source tarballs. In that case you won't want the build scripts messing around with git. will look for in the current directory, then in the scripts directory. This means that it'll execute any "" in the directory you invoke it in, so keep that in mind when running builds on untrusted branches.

Just cd to the source tree and invoke from there:

For example:

    cd \path\to\pg_source_tree

If using, the scripts won't use git and you don't need it installed. In this mode, " postgresql-clean" and " clean" will use "src\tools\msvc\clean.bat dist" to clean the source tree, rather than using git.

(Optional) Download library source archives

The build tools will download the source archives into LIBDIR\pkg for you if it can't find them.

If you like, you can create LIBDIR\pkg and copy the source archives from somewhere yourself for offline use. The filenames the build scripts look for are specified in settings-default.mak and can be overridden in settings.mak.

Be warned that "build{cwd|git}.pl really-clean" will delete LIBDIR and its contents, including any source packages you put there.


Set up your Visual Studio or Windows SDK environment for the build target you want. Either use the Start menu option to launch a suitable prompt if you want the default settings, or preferably open a new ordinary Command Prompt and use SetEnv.cmd (SDK) or vcvars.bat (Studio) to set the environment up.

For windows SDK 7.1 32-bit release builds you'd use:

"c:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.Cmd" /x86 /release /xp

For options:

"c:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.Cmd" /?

The main options are "/x86" vs "/x64" and "/Debug" vs "/Release". You probably want to pass "/xp" for 32-bit builds and "/2008" for 64-bit builds.


In a command prompt that's had its environment set up as per "SET UP VISUAL STUDIO ENVIRONMENT", do a full build using:

cd \some\postgresql\sources\
\path\to\pg_build_win\ postgresql

or to use automatically managed git trees:  postgresql 

Supported targets are:


  • postgresql: Build PostgreSQL and its dependencies
  • postgresql-check: Run the test suite
  • postgresql-clean: Clean postgresql working tree, leave libraries alone


If you want to build individual libraries, each library Makefile has "libname" and "libname-clean" targets, eg:

  • zlib
  • zlib-clean


To get a tree of installed PostgreSQL binaries, contrib modules, etc including the library dependencies, use the "install" target.

By default, "install" will install the binaries to a directory named "binaries" under PGBUILDDIR. Change this if desired by setting PGINSTALLDIR.

If you want just the PostgreSQL install but not the libraries, use "postgresql-install".

The interpreters for the PLs are not copied over. Neither is the Visual C++ redist for your SDK, which will need to be installed before the compiled binaries will run on another machine.


  • clean - remove built libraries and clean PostgreSQL working tree
  • really-clean: Remove built libraries and downloaded files, delete PostgreSQL checkout and working tree


SDK 7.1 / Visual Studio 2010 conflict with Visual Studio 2012

If you have Visual Studio 2012 installed on your computer, Windows SDK 7.1 may fail to compile programs with errors like:

LINK : fatal error LNK1123: failure during conversion to COFF: file invalid or corrupt

This is a known issue with Visual Studio 2010 that also appears to affect SDK 7.1, since the SDK uses the same compiler suite. The problem was fixed in Visual Studio 2010 SP1, but not in SDK 7.1. To work around the problem you must install Visual C++ Express Edition 2010 and then the Visual Studio 2010 Service Pack 1 update.

SDK 7.1 install fails

One possible cause of a Microsoft Windows SDK 7.1 install failure is if newer versions of the Visual C++ 2010 redistributable runtime are installed. Many program installers will add these for you.

The only workaround I'm aware of is to uninstall any VC++ 2010 redistributibles, install the SDK, then reinstall the redistributibles. Note that uninstalling the redistributibles will cause some programs on your computer to fail to run until they're reinstalled.

You can get the redists from:

Permission denied errors when cleaning

Unlike POSIX systems, on Windows a file or folder that is open by a program cannot be deleted or renamed.

If you've run regression tests and they've crashed out without properly terminating the server they've started, you will find that you can't clean your working directory and you'll get "permission denied" errors for files/folders you obviously do have full ownership and control of.

Open up Process Explorer (preferered) or Task Manager. Now find and terminate the problem processes - look for psql.exe, pg_regress.exe and postgres.exe . If you have a real PostgreSQL instance you use for real work on this machine, be careful not to terminate it.

postgres.exe or git.exe hung at max cpu forever, won't End Task

There appears to be a problem with building and testing PostgreSQL inside deep directory trees (130+ characters, roundabout). See:

Other SDKs

Test reports for SDKs and Visual Studio versions listed as "untested" below would be greatly appreciated, particularly if they come with patches fixing any issues encountered. Add a GitHub issue with the results, or better, send a pull request with a docs patch.

Visual Studio 6 is not and will never be supported.

Visual Studio 8 (2005)


Visual Studio 9 (2008)


Environment setup with vcvarsall.bat:

"C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" /?

Visual Studio 10 (2010)

Visual Studio 2010 and its express edition should work fine with no changes. Environment setup with vcvarsall.bat.

"C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" /?

vcvarsall.bat does not set TARGET_CPU, CONFIGURATION or PLATFORMTOOLSET so you must set these environment variables yourself.

Visual Studio 11 (2012)

Installing Visual Studio 2012 breaks Visual Studio 2010 (pre-SP1) and Windows SDK 7.1 . See TROUBLESHOOTING.

Environment setup with vcvarsall.bat or VsDevCmd.bat:

"C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\vcvarsall.bat" /?
"C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\Tools\VsDevCmd.bat"


Microsoft Platform SDK for Windows XP SP2


Microsoft Windows SDK for Windows 7 and .NET Framework 4 (7.1)

Known working, recommended. Environment setup with setenv.cmd.

"C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.cmd" /?

Known compatibility issues with Visual Studio 2010, .NET 4.5, and Visual Studio 2012. See TROUBLESHOOTING.

Microsoft Windows SDK for Windows 8 and .NET Framework 4.5 (v8.0a)

You cannot compile PostgreSQL with this SDK because this version of the SDK does not include standalone compilers and build tools.

You must use Visual Studio 2012 or the express edition instead.

Obsolete versions

The following obsolete SDK and Visual Studio releases are not supported and will never be supported by pg_build_win. Patches adding support will be rejected.

  • Visual Studio 97
  • Visual Studio 6
  • Visual Studio 7 (.NET 2002, 2003)
  • All Microsoft Platform SDK releases prior to Microsoft Platform SDK for Windows XP SP2

Unlisted SDKs

If you have test results for an SDK not listed above, please add a GitHub issue with the results.


Compiling PostgreSQL from source on Windows: Windows SDK unattended: ActivePerl unattended: ActiveTCL unattended: Python unattended:

Something went wrong with that request. Please try again.