2ndQuadrant is now part of EDB

Bringing together some of the world's top PostgreSQL experts.

2ndQuadrant | PostgreSQL
Mission Critical Databases
  • Contact us
  • Support & Services
    • Support
      • 24/7 PostgreSQL Support
      • Developer Support
    • DBA Services
      • Remote DBA
      • Database Monitoring
    • Consulting Services
      • Health Check
      • Performance Tuning
      • Database Security Audit
      • PostgreSQL Upgrade
    • Migration Services
      • Migrate to PostgreSQL
      • Migration Assessment
  • Products
    • Postgres-BDR ®
    • PostgreSQL High Availability
    • Kubernetes Operators for BDR & PostgreSQL
    • Managed PostgreSQL in the Cloud
    • Installers
      • Postgres Installer
      • 2UDA
    • 2ndQPostgres
    • pglogical
    • Barman
    • repmgr
    • OmniDB
    • SQL Firewall
    • Postgres-XL
  • Downloads
    • Installers
      • Postgres Installer
      • 2UDA – Unified Data Analytics
    • Whitepapers
      • Business Case for PostgreSQL Support
      • AlwaysOn Postgres
      • PostgreSQL with High Availability
      • Security Best Practices
      • BDR
    • Case Studies
      • Performance Tuning
        • BenchPrep
        • tastyworks
      • Distributed Clusters
        • ClickUp
        • European Space Agency (ESA)
        • Telefónica del Sur
        • Animal Logic
      • Database Administration
        • Agilis Systems
      • Professional Training
        • Met Office
        • London & Partners
      • Database Upgrades
        • Alfred Wegener Institute (AWI)
      • Database Migration
        • International Game Technology (IGT)
        • Healthcare Software Solutions (HSS)
        • Navionics
  • Postgres Learning Center
    • Webinars
      • Upcoming Webinars
      • Webinar Library
    • Whitepapers
      • Business Case for PostgreSQL Support
      • AlwaysOn Postgres
      • PostgreSQL with High Availability
      • Security Best Practices
      • BDR
    • Blog
    • Training
      • Course Catalogue
    • Case Studies
      • Performance Tuning
        • BenchPrep
        • tastyworks
      • Distributed Clusters
        • ClickUp
        • European Space Agency (ESA)
        • Telefónica del Sur
        • Animal Logic
      • Database Administration
        • Agilis Systems
      • Professional Training
        • Met Office
        • London & Partners
      • Database Upgrades
        • Alfred Wegener Institute (AWI)
      • Database Migration
        • International Game Technology (IGT)
        • Healthcare Software Solutions (HSS)
        • Navionics
    • Books
      • PostgreSQL 11 Administration Cookbook
      • PostgreSQL 10 Administration Cookbook
      • PostgreSQL High Availability Cookbook – 2nd Edition
      • PostgreSQL 9 Administration Cookbook – 3rd Edition
      • PostgreSQL Server Programming Cookbook – 2nd Edition
      • PostgreSQL 9 Cookbook – Chinese Edition
    • Videos
    • Events
    • PostgreSQL
      • PostgreSQL – History
      • Who uses PostgreSQL?
      • PostgreSQL FAQ
      • PostgreSQL vs MySQL
      • The Business Case for PostgreSQL
      • Security Information
      • Documentation
  • About Us
    • About 2ndQuadrant
    • What Does “2ndQuadrant” Mean?
    • 2ndQuadrant’s Passion for PostgreSQL
    • News
    • Careers
    • Team Profile
  • Blog
  • Menu Menu
You are here: Home1 / Blog2 / Eisentraut's PlanetPostgreSQL3 / Developing PostgreSQL for Windows, Part 2
Developing PostgreSQL for Windows, Part 2
Peter Eisentraut

Developing PostgreSQL for Windows, Part 2

March 4, 2020/0 Comments/in Eisentraut's PlanetPostgreSQL, PostgreSQL /by Peter Eisentraut

In the previous blog post, we discussed the different Windows build variants that PostgreSQL supports. In this post, we’ll discuss how, as a Unix-based developer, you can check whether your patch might work on Windows. (For simplicity, I’ll say “Unix” to mean Linux, BSD, macOS, and similar.)

First, there are a few ways to check your patch without having to have Windows at all.

If your patch touches the build system, for example by adding new files, or more likely by adding conditionals, new build options, or additional ad-hoc logic, it might break the MSVC build scripts, which parse the Unix makefiles, as we discussed last time. But you can actually run those scripts on Unix as well. There is (almost) nothing specific to Windows in them, since all they really do is parse one set of files and produce another. You can just run

perl src/tools/msvc/mkvcbuild.pl

and see what happens. This works as of commit 73c8596. (Maybe save your work beforehand, because this might overwrite some generated files to are used by your local non-Windows configuration). This will produce project files for Visual Studio that you can’t do much with, but you can check whether the script ran at all, you can compare the output before and after, or if you have made “blind edits” to any of the files under src/tools/msvc/ you can verify those to some extent.

Another way is to exercise build options that are typically associated with Windows. Which one of these is useful depends on what your patch changes. For example, Windows builds with HAVE_UNIX_SOCKETS undefined, so testing that manually might be worthwhile if you are making changes in network code. (But this is going away, since Windows does actually support Unix-domain sockets now.) Similarly, HAVE_WORKING_LINK is undefined on Windows, although the impact of that is small (and it’s also going away; sometimes a consequence of writing blog posts like this one is to discover that the problems you wanted to describe shouldn’t be there in the first place, and you go fix them). You can change both of these options by editing src/include/pg_config_manual.h. Another important option is EXEC_BACKEND, which replaces the Unix-style fork() call with a fork() plus exec() implementation that can be mapped to CreateProcess() on Windows. This actually breaks surprisingly rarely, but if it does, you can debug and fix it entirely on a Unix system. To enable EXEC_BACKEND, you can either edit src/Makefile.global and add -DEXEC_BACKEND to CPPFLAGS, or perhaps add a define to src/include/pg_config_manual.h. (Not sure why this is different from the other ones; perhaps another thing to fix sometime. [update: also fixed])

When these options are exhausted, then it’s perhaps time to spin up a real Windows system. I want to discuss two options that are easily available to the casual developer. First, you can download a demo Windows image from Microsoft and import it into VirtualBox or something similar. The current links for that that I can find are:

  • https://developer.microsoft.com/en-us/windows/downloads/virtual-machines/
  • https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/

The second one of these is meant for browser testing, so perhaps the first one is better now, but the browser-testing route has been popular for some time. These are free of charge evaluation copies, but please read the license yourself.

Second, you can launch a cloud instance at a cloud computing provider. I’m not going to name them, but you know who they are.

When you have the Windows operating system running, I recommend installing MSYS2. (The first download link above from Microsoft also has Visual Studio installed, if you prefer that.) Use a browser (presumably Internet Explorer or whatever it’s called now) to go to msys2.org, run the installer, and in a few minutes you will have a full MSYS2/MinGW environment ready. Follow the instructions on the msys2.org web site to get the package manager up to date. Then, open a MinGW (not MSYS2) shell from the Start menu and run the following to get the packages needed for PostgreSQL development:

pacman -S git

Now you can git clone the repository. While that runs …

pacman -S ${MINGW_PACKAGE_PREFIX}-gcc ${MINGW_PACKAGE_PREFIX}-gettext ${MINGW_PACKAGE_PREFIX}-icu ${MINGW_PACKAGE_PREFIX}-libxml2 ${MINGW_PACKAGE_PREFIX}-libxslt ${MINGW_PACKAGE_PREFIX}-openssl bison flex make diffutils

MINGW_PACKAGE_PREFIX is an environment variable that is set for you, so type in the commands like that. (It will be different for 32-bit and 64-bit MinGW.) The packages without prefix are MSYS2 (i.e., Cygwin) packages. See part 1 again if this is confusing. At this point, you’ll have a full MinGW build environment for PostgreSQL. You can run configure, make, make check, and so on. Additional packages may be required for some build options, but not all options actually work; for example no Readline (use Cygwin for that).

In the next part of this series, I will look at automatic build/continuous integration options for Windows that can be used to verify patches.

Tags: PostgreSQL, windows
Share this entry
  • Share on Facebook
  • Share on Twitter
  • Share on WhatsApp
  • Share on LinkedIn
0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Search

Get in touch with us!

Recent Posts

  • Random Data December 3, 2020
  • Webinar: COMMIT Without Fear – The Beauty of CAMO [Follow Up] November 13, 2020
  • Full-text search since PostgreSQL 8.3 November 5, 2020
  • Random numbers November 3, 2020
  • Webinar: Best Practices for Bulk Data Loading in PostgreSQL [Follow Up] November 2, 2020

Featured External Blogs

Tomas Vondra's Blog

Our Bloggers

  • Simon Riggs
  • Alvaro Herrera
  • Andrew Dunstan
  • Craig Ringer
  • Francesco Canovai
  • Gabriele Bartolini
  • Giulio Calacoci
  • Ian Barwick
  • Marco Nenciarini
  • Mark Wong
  • Pavan Deolasee
  • Petr Jelinek
  • Shaun Thomas
  • Tomas Vondra
  • Umair Shahid

PostgreSQL Cloud

2QLovesPG 2UDA 9.6 backup Barman BDR Business Continuity community conference database DBA development devops disaster recovery greenplum Hot Standby JSON JSONB logical replication monitoring OmniDB open source Orange performance PG12 pgbarman pglogical PG Phriday postgres Postgres-BDR postgres-xl PostgreSQL PostgreSQL 9.6 PostgreSQL10 PostgreSQL11 PostgreSQL 11 PostgreSQL 11 New Features postgresql repmgr Recovery replication security sql wal webinar webinars

Support & Services

24/7 Production Support

Developer Support

Remote DBA for PostgreSQL

PostgreSQL Database Monitoring

PostgreSQL Health Check

PostgreSQL Performance Tuning

Database Security Audit

Upgrade PostgreSQL

PostgreSQL Migration Assessment

Migrate from Oracle to PostgreSQL

Products

HA Postgres Clusters

Postgres-BDR®

2ndQPostgres

pglogical

repmgr

Barman

Postgres Cloud Manager

SQL Firewall

Postgres-XL

OmniDB

Postgres Installer

2UDA

Postgres Learning Center

Introducing Postgres

Blog

Webinars

Books

Videos

Training

Case Studies

Events

About Us

About 2ndQuadrant

What does 2ndQuadrant Mean?

News

Careers 

Team Profile

© 2ndQuadrant Ltd. All rights reserved. | Privacy Policy
  • Twitter
  • LinkedIn
  • Facebook
  • Youtube
  • Mail
Researching PostGIS slowness (2019 edition) Researching PostGIS slowness (2019 edition) Creating a PostgreSQL procedural language - Part 4 - Handling Input Parameters Creating a PostgreSQL procedural language – Part 4 – Handling Input...
Scroll to top
×