Subject: [postgresql-interfaces/psqlodbc] PR #6: Use mimalloc to improve performance and reduce memory allocation lock contention

From: "apgrucza (@apgrucza)" <[email-masked]>
Date: Wed, 06 Mar 2024 00:37:41 +0000

We have a multi-threaded Windows application that was experiencing delays due to high lock contention in memory allocations from the PostgreSQL ODBC driver. We tried modifying the driver to use [mimalloc](https://github.com/microsoft/mimalloc), which is a memory allocator with better performance characteristics. After deploying this change, the delays due to lock contention disappeared. It has been running on thousands of our production deployments for 9 months without issue.

I've created this pull request so that others can benefit from this change by building the driver with the `_MIMALLOC_` symbol defined and linking to the mimalloc library. If building on Windows, `BuildAll.ps1` accepts a `-UseMimalloc` argument that does this for you (requires a toolset of `v141`, `v142` or later). Below is an example of how to build with mimalloc on Windows:

```
.\BuildAll.ps1 -Platform x64 -Toolset v141 -UseMimalloc
```

Currently the usage of mimalloc is off by default, but I'd like to get people's thoughts on whether it should be enabled by default.

---

From: "davecramer (@davecramer)" <[email-masked]>
Date: Thu, 28 Mar 2024 11:28:53 +0000

I'm looking at enabling github actions on this repo. Once I get that working I can look at this PR

---

From: "davecramer (@davecramer)" <[email-masked]>
Date: Thu, 28 Mar 2024 16:13:49 +0000

any chance you can test the installers from https://github.com/postgresql-interfaces/psqlodbc/actions/runs/8469691901

---

From: "apgrucza (@apgrucza)" <[email-masked]>
Date: Tue, 16 Apr 2024 07:13:46 +0000

Sorry I was off for a few weeks. Do you still need these installers tested?

---

From: "davecramer (@davecramer)" <[email-masked]>
Date: Wed, 17 Apr 2024 17:44:14 +0000

@apgrucza yes please. I have been working on automating the release process.
Latest is https://github.com/postgresql-interfaces/psqlodbc/actions/runs/8723906820

---

From: "davecramer (@davecramer)" <[email-masked]>
Date: Thu, 18 Apr 2024 12:23:15 +0000

Can you rebase and add your tests to the github actions ?

---

From: "apgrucza (@apgrucza)" <[email-masked]>
Date: Mon, 22 Apr 2024 07:20:20 +0000

I ran the `psqlODBC x64 Installer` and successfully used `pyodbc` to connect to and query a PostgreSQL database using the `PostgreSQL Unicode(x64)` driver.

> Can you rebase and add your tests to the github actions ?

Not sure which tests you are referring to. This pull request does not add any tests.

---

From: "davecramer (@davecramer)" <[email-masked]>
Date: Mon, 22 Apr 2024 12:36:41 +0000

@apgrucza right, but wouldn't we have to build with your option turned on, and then run all of the tests ?

---

From: "davecramer (@davecramer)" <[email-masked]>
Date: Thu, 25 Apr 2024 09:53:02 +0000

@apgrucza looks like the test is failing ?

---

From: "apgrucza (@apgrucza)" <[email-masked]>
Date: Thu, 25 Apr 2024 12:30:18 +0000

> @apgrucza looks like the test is failing ?

@davecramer my changes are now complete. Please try again.

---

From: "davecramer (@davecramer)" <[email-masked]>
Date: Fri, 26 Apr 2024 13:00:35 +0000

Thanks!

---

From: "apgrucza (@apgrucza)" <[email-masked]>
Date: Wed, 01 May 2024 04:31:46 +0000

> any chance you can test the installers from https://github.com/postgresql-interfaces/psqlodbc/actions/runs/8469691901

@davecramer I tried running the 64-bit installer again (the linked artifact has expired but I still have the file), and I now get the following error:

_Error installing ODBC driver: PostgreSQL ANSI(x64), ODBC error 13: The setup routines for the PostgreSQL ANSI(x64) ODBC driver could not be loaded due to system error code 126: The specified module could not be found. (C:\Program Files\psqlODBC\1600\bin\psqlodbc30a.dll).. Verify that the file PostgreSQL ANSI(x64) exists and that you can access it._

Not sure why I didn't get this the first time around. The same error occurs whether I install fresh or upgrade from an old version. I've tested on two different machines. The `psqlodbc30a.dll` file does exist, so I wonder whether it's failing due to a missing dependency?

---

From: "apgrucza (@apgrucza)" <[email-masked]>
Date: Wed, 01 May 2024 06:23:49 +0000

The x86 installer works fine though.

---

From: "davecramer (@davecramer)" <[email-masked]>
Date: Wed, 01 May 2024 10:53:37 +0000

@apgrucza can you try https://github.com/postgresql-interfaces/psqlodbc/releases/tag/REL-16_00_0003 ?
Thanks for testing this!

---

From: "apgrucza (@apgrucza)" <[email-masked]>
Date: Wed, 01 May 2024 11:14:57 +0000

@davecramer that link only contains the x86 installer. I did test that one (in addition to the build artifacts) and it installed without error. The problem seems to be just with the x64 installer.

I don't think it's related, but I'm also curious to know why the version of `libpq.dll` in these packages (both x86 and x64) is 17.0.0.0, but the latest version of PostgreSQL is 16.2.

---

From: "davecramer (@davecramer)" <[email-masked]>
Date: Wed, 01 May 2024 12:45:34 +0000

Interesting. As for 17. it's because I build against head. Presumably the next release will be against 17
The fact that all the artifacts are not there is a problem though.
Thanks for testing!

---

From: "apgrucza (@apgrucza)" <[email-masked]>
Date: Wed, 01 May 2024 12:59:48 +0000

Another question. Was it a deliberate decision to use the latest version of Visual C++ (VC17) in the GitHub Actions? Looking at the build script, [the "official" version to build against is VC15](https://github.com/postgresql-interfaces/psqlodbc/blob/3869efe76653ce9e56edf10478e30dcf1072123c/winbuild/MSProgram-Get.psm1#L43) (it will use that version even if newer versions are installed). When VC16 was added to the build script, I think it was [for development purposes only](https://github.com/postgresql-interfaces/psqlodbc/blob/3869efe76653ce9e56edf10478e30dcf1072123c/docs/release.html#L77) (rather than for building releases).

I'm not opposed to building against VC17, but the change should be documented as I believe it may require users to install a newer version of the Microsoft Visual C++ Redistributable. And [this page](https://learn.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist?view=msvc-170#notes) suggests if psqlODBC required the VC17 runtime, it would no longer run on Windows XP:

> The last version of the Visual C++ Redistributable that works on Windows XP shipped in Visual Studio 2019 version 16.7 (file versions starting with 14.27).

---

From: "davecramer (@davecramer)" <[email-masked]>
Date: Wed, 01 May 2024 13:03:14 +0000

Well "deliberate" is an interesting word. The better word would be "ignorant" I'll switch it to 15 if that is going to stop it from working on XP.

---

From: "davecramer (@davecramer)" <[email-masked]>
Date: Wed, 01 May 2024 13:12:11 +0000

```
Windows XP Support: Microsoft ended support for Windows XP on April 8, 2014. Current versions of the Visual C++ Redistributable for Visual Studio 2015-2022 only support Windows 7, 8.1, 10, and 11. The last version of the Visual C++ Redistributable that works on Windows XP shipped in Visual Studio 2019 version 16.7 (file versions starting with 14.27). The Redistributable is available in the [my.visualstudio.com Downloads](https://my.visualstudio.com/Downloads/) section as Visual C++ Redistributable for Visual Studio 2019 (version 16.7). Use the Search box to find this version. To download the files, select the platform and language you need, and then choose the Download button.
```
So the question is do we need/want to support XP ?

---

From: "davecramer (@davecramer)" <[email-masked]>
Date: Wed, 01 May 2024 13:40:28 +0000

Looks like we also need to add all of the dll's used

---

From: "davecramer (@davecramer)" <[email-masked]>
Date: Wed, 01 May 2024 21:31:38 +0000

Can you try these https://github.com/davecramer/psqlodbc/releases/tag/REL-16_00_0005

---

From: "apgrucza (@apgrucza)" <[email-masked]>
Date: Thu, 02 May 2024 02:21:55 +0000

> So the question is do we need/want to support XP ?

On the mailing list I have noticed a few queries from people running legacy systems. But to be honest I don't really know if it currently even works on Windows XP. [This post](https://www.postgresql.org/message-id/[email-masked]) suggests it may have stopped working on Windows XP since version 11. Nobody should really be using an operating system that was retired 10 years ago and expect new software to run on it.

> Can you try these https://github.com/davecramer/psqlodbc/releases/tag/REL-16_00_0005

Still getting the same error:

![image](https://github.com/postgresql-interfaces/psqlodbc/assets/46910040/6652c8a3-01fe-47de-9bd1-cd14737ff1cb)

The x86 installer works fine. It must be something to do with the build environment, because it works if I build the x64 installer myself locally.

---

From: "davecramer (@davecramer)" <[email-masked]>
Date: Thu, 02 May 2024 09:26:04 +0000

Interesting, If I install it on a windows system it works. Thanks for checking. I will keep digging.

I uninstall the previous one first. Are you doing yours on a clean system ?

---

From: "apgrucza (@apgrucza)" <[email-masked]>
Date: Thu, 02 May 2024 09:33:31 +0000

The error occurs regardless of whether I uninstall first. I’ve tested on two different systems. They are not new machines, but both have no problems when installing previous versions of the x64 driver.

---

From: "davecramer (@davecramer)" <[email-masked]>
Date: Thu, 02 May 2024 09:35:09 +0000

Hmmm OK, so to be clear I am using the installer. The MSI file. I think you may be using the setup file?

---

From: "davecramer (@davecramer)" <[email-masked]>
Date: Thu, 02 May 2024 09:37:37 +0000

I just tried the setup file and it worked fine. Can you send me the file that works on your end? Perhaps we can figure out what is different about the files ? My email is [email-masked]

---

From: "apgrucza (@apgrucza)" <[email-masked]>
Date: Thu, 02 May 2024 10:58:02 +0000

I get the same error regardless of whether I use the MSI installer or the setup EXE. I was testing the files in the release you just made. So:

- [psqlodbc_x64.msi](https://github.com/davecramer/psqlodbc/releases/download/REL-16_00_0005/psqlodbc_x64.msi) (this does not work)
- [psqlodbc_x86.msi](https://github.com/davecramer/psqlodbc/releases/download/REL-16_00_0005/psqlodbc_x86.msi) (this works)

If both are working for you then something on my systems must be causing it to fail. Perhaps the presence (or lack of) a particular DLL.

---

From: "apgrucza (@apgrucza)" <[email-masked]>
Date: Thu, 02 May 2024 11:55:38 +0000

I loaded `psqlodbc30a.dll` from both REL-16_00_0005 installers into [Dependencies](https://github.com/lucasg/Dependencies) to compare. For some reason the x64 one tries to load extra DLLs (libcrypto and libssl) via `libq.dll` but the x86 one doesn't. These DLLs fail to load (module could not be found on disk), which explains why only the x64 installer fails.

**x86**
![image](https://github.com/postgresql-interfaces/psqlodbc/assets/46910040/9f894450-b672-42e6-ae8f-011bec80a4e9)

**x64**
![image](https://github.com/postgresql-interfaces/psqlodbc/assets/46910040/ab3dfaf5-1216-4aad-96c9-77d9b6bf9a8b)

Neither MSI files include these DLLs:

**x86**
![image](https://github.com/postgresql-interfaces/psqlodbc/assets/46910040/ecefa2c6-236e-4df7-bac9-38e19f99f7f4)

**x64**
![image](https://github.com/postgresql-interfaces/psqlodbc/assets/46910040/364130bb-2428-4950-a8e1-428982d483d7)

If I compare with the MSIs from the last official release at https://www.postgresql.org/ftp/odbc/versions/msi/, libcrypto and libssl DLLs are present (and the x64 one has a few more: libiconv, libintl, libwinpthread):

**x86**
![image](https://github.com/postgresql-interfaces/psqlodbc/assets/46910040/55fad8e6-1497-46e8-bed2-0bd0f5d9c23c)

**x64**
![image](https://github.com/postgresql-interfaces/psqlodbc/assets/46910040/afff3e2c-bd5a-4788-a6d7-28a8718e3fc0)

So, I think the problem lies with these DLLs being absent from the MSI files.

---

From: "davecramer (@davecramer)" <[email-masked]>
Date: Thu, 02 May 2024 12:10:37 +0000

AHA, good detective work. Which explains why it works on my machine and not yours.

Thanks!

---

From: "apgrucza (@apgrucza)" <[email-masked]>
Date: Thu, 02 May 2024 12:19:30 +0000

And when I build the installer locally, all those extra libs are included in the MSI file.

I noticed `configuration.xml` in the GitHub workflow references the directories from your PostgreSQL build (`d:\postgresql86` and `d:\postgresql`) rather than the directory that the EDB installer creates. On my system I didn't have to build PostgreSQL. I just ran the EDB installer, which creates `C:\Program Files\PostgreSQL\16`, and then my `configuration.xml` simply references this directory:

```xml
    <libpq version="y">
      <include>C:\Program Files\PostgreSQL\16\include</include>
      <lib>C:\Program Files\PostgreSQL\16\lib</lib>
      <bin>C:\Program Files\PostgreSQL\16\bin</bin>
    </libpq>
```

Perhaps you should do the same in the GitHub workflow? You may need change the `--enable-components` option for the `include` directory to be created. Once you do this, I don't think you need the GitHub workflow to build PostgreSQL at all.

Not sure if this will fix the problem, but it's worth a try and should simplify the workflow too.

---

From: "davecramer (@davecramer)" <[email-masked]>
Date: Thu, 02 May 2024 16:11:48 +0000

Well I added the EDB one after, since the XML tests failed and I was unable to build PostgreSQL with XML on windows.
We still need the x86 one as the EDB build is 64 bit

---

From: "apgrucza (@apgrucza)" <[email-masked]>
Date: Fri, 03 May 2024 14:16:27 +0000

As a test, I updated `configuration.xml` in my fork to point to the EDB one (for x64):

```xml
  <x64>
    <libpq version="y">
    ...
```

This time the x64 MSI produced by the GitHub workflow included the extra DLLs (libcrypto, libssl, libiconv, libintl, libwinpthread) and installed successfully. But as you point out, EDB does not provide an x86 build for PostgreSQL 16.

I compared `d:\postgresql\lib` with `C:\Program Files\PostgreSQL\16\lib` and there were a lot of differences. The former was missing files such as `libcrypto.lib` and `libssl.lib`. Perhaps EDB have a different build process. Regardless, it's probably better to build a stable release from https://www.postgresql.org/ftp/source/ rather than from HEAD.

---

From: "davecramer (@davecramer)" <[email-masked]>
Date: Fri, 03 May 2024 16:43:44 +0000

> I compared `d:\postgresql\lib` with `C:\Program Files\PostgreSQL\16\lib` and there were a lot of differences. The former was missing files such as `libcrypto.lib` and `libssl.lib`. Perhaps EDB have…

Building from source is the answer. I guess I'll have to figure that out.

Dave

---

From: "davecramer (@davecramer)" <[email-masked]>
Date: Fri, 03 May 2024 19:49:44 +0000

The instructions on how to create the installers are not helpful here.

---

From: "davecramer (@davecramer)" <[email-masked]>
Date: Sat, 04 May 2024 00:01:26 +0000

I found the problem. I deleted
```$(TARGET_CPU)\psqlodbc_$(TARGET_CPU).msm: psqlodbcm_cpu.wxs $(DRIVER_FILES)
	echo Building Installer Merge Module
        $(CANDLE) -nologo -dLIBPQMEM0="libssl-3-x64.dll" -dLIBPQMEM1="libcrypto-3-x64.dll" -dLIBPQMEM2="libintl-9.dll" -dLIBPQMEM3="libwinpthread-1.dll" -dLIBPQMEM4="libiconv-2.dll" -dLIBPQMEM5="" -dLIBPQMEM6="" -dLIBPQMEM7="" -dLIBPQMEM8="" -dLIBPQMEM9="" -dPlatform="$(TARGET_CPU)" -dVERSION=$(PG_VER) -dLIBPQBINDIR=$(PG_BIN) -dLIBPQMSVCDLL="" -dLIBPQMSVCSYS="" -dPODBCMSVCDLL=$(VCRT_DLL) -dPODBCMSVPDLL=$(MSVCP_DLL) -dPODBCMSVCSYS="" -dPODBCMSVPSYS="" -dNoPDB="False" -dBINBASE=".." -o .\x64\psqlodbcm.wixobj psqlodbcm_cpu.wxs
	$(LIGHT) -nologo -o $(TARGET_CPU)\psqlodbc_$(TARGET_CPU).msm $(TARGET_CPU)\psqlodbcm.wixobj

$(TARGET_CPU)\psqlodbc_$(TARGET_CPU).msi: psqlodbc_cpu.wxs $(DRIVER_FILES)
	echo Building Installer
	$(CANDLE) -nologo -dPlatform="$(TARGET_CPU)" -dVERSION=$(POSTGRESDRIVERVERSION) -dSUBLOC=$(SUBLOC) -dPRODUCTCODE=$(PRODUCTCODE) -o $(TARGET_CPU)\psqlodbc.wixobj psqlodbc_cpu.wxs
	$(LIGHT) -nologo -ext WixUIExtension -cultures:en-us -o $(TARGET_CPU)\psqlodbc_$(TARGET_CPU).msi $(TARGET_CPU)\psqlodbc.wixobj
	cscript modify_msi.vbs $(TARGET_CPU)\psqlodbc_$(TARGET_CPU).msi

```

out of installer.mak. This is where the extra files are added

---

From: "apgrucza (@apgrucza)" <[email-masked]>
Date: Sat, 04 May 2024 14:21:39 +0000

When was that? [installer.mak](https://github.com/postgresql-interfaces/psqlodbc/blob/main/installer/installer.mak) hasn't been changed for 10 years.

---

From: "davecramer (@davecramer)" <[email-masked]>
Date: Sat, 04 May 2024 18:48:03 +0000

Not sure, all I know is that it is in the original code, and that is where the additional dll's are added

---

From: "davecramer (@davecramer)" <[email-masked]>
Date: Mon, 06 May 2024 10:51:46 +0000

So looking at this some more, https://github.com/postgresql-interfaces/psqlodbc/blob/3869efe76653ce9e56edf10478e30dcf1072123c/installer/psqlodbcm_cpu.wxs#L106-L135 is where those variables are used. 
It's becoming clear to me that the actual release steps are not documented anywhere. 

You are correct installer.mak hasn't changed and I found the code in a private repo that I have access to. 

Either way we need to fix the release code to include those libraries.

Also need to figure out how to get the 32bit versions of those libraries.

---

From: "apgrucza (@apgrucza)" <[email-masked]>
Date: Mon, 06 May 2024 11:55:26 +0000

I just took a deeper look too.

`installer.mak` is not even used by `buildInstallers.ps1`, so changing that file won't help. In `buildInstallers.ps1` there is [a call to Get-RelatedDlls](https://github.com/postgresql-interfaces/psqlodbc/blob/3869efe76653ce9e56edf10478e30dcf1072123c/installer/buildInstallers.ps1#L242) which uses `dumpbin.exe` to inspect `libpq.dll` and figure out its dependencies. As long as the `bin` directory referenced in `configuration.xml` contains these libraries, `dumpbin.exe` will find them and they will be included in the installer. That's why it worked when I changed `configuration.xml` to reference the EDB installation (`Get-RelatedDlls` returned `libssl-3-x64.dll libcrypto-3-x64.dll libintl-9.dll libwinpthread-1.dll libiconv-2.dll`). So, there should be no need to change the release code.

As you say, we still need to figure out how to get the 32-bit versions of those libraries. @winpg was the one who always prepared and announced psqlODBC releases. Perhaps he could provide some insight here, or is he also unavailable?

---

From: "apgrucza (@apgrucza)" <[email-masked]>
Date: Mon, 06 May 2024 12:13:47 +0000

The EDB installer must include those extra DLLs because they are required by PostgreSQL. So I checked the Windows build instructions for PostgreSQL and it lists the [requirements](https://www.postgresql.org/docs/current/install-windows-full.html#INSTALL-WINDOWS-FULL-REQUIREMENTS). One of them is OpenSSL, and it provides a link to download binaries. I downloaded [OpenSSL v3.3.0 Light](https://slproweb.com/products/Win32OpenSSL.html) and found that it includes both the `libssl-3` and `libcrypto-3` DLLs. So perhaps all we need to do is get those into `d:\postgresql86\bin`.

---

From: "davecramer (@davecramer)" <[email-masked]>
Date: Mon, 06 May 2024 12:48:21 +0000

Yes, I am in the process of doing that now!. Thanks

---

From: "davecramer (@davecramer)" <[email-masked]>
Date: Wed, 08 May 2024 09:23:53 +0000

can you check the installers from https://github.com/postgresql-interfaces/psqlodbc/actions/runs/8992393964

---

From: "apgrucza (@apgrucza)" <[email-masked]>
Date: Wed, 08 May 2024 12:35:36 +0000

Both installers now work without errors. However, the x86 installer still does not contain the libssl and libcrypto DLLs.

---

From: "apgrucza (@apgrucza)" <[email-masked]>
Date: Wed, 08 May 2024 12:51:18 +0000

One problem I can see is that this:

```
cp c:\openssl32\*.dll d:\postgresql86\bin
```

needs to be changed to this:

```
cp c:\openssl32\bin\*.dll d:\postgresql86\bin
```

---

From: "apgrucza (@apgrucza)" <[email-masked]>
Date: Wed, 08 May 2024 13:49:54 +0000

BTW the usage of `actions/cache` is causing certain steps to be skipped when they shouldn't be. For example, the "build postgresx86" step in [this run](https://github.com/postgresql-interfaces/psqlodbc/actions/runs/8992393964) was skipped even though the [commit that triggered it](https://github.com/postgresql-interfaces/psqlodbc/commit/03dec03835839a90948237af271317a54a0575a3) changed that step. Not sure what the best solution to this is, but one option is to include in the [cache key](https://github.com/actions/cache?tab=readme-ov-file#creating-a-cache-key) a hash of all files that affect the contents of `d:\postgresql86`, including `.github/workflows/main.yml` itself.

---

From: "davecramer (@davecramer)" <[email-masked]>
Date: Wed, 08 May 2024 13:52:29 +0000

> cp c:\openssl32\bin\*.dll d:\postgresql86\bin

The dll's are installed in both places so it is currently correct.

---

From: "davecramer (@davecramer)" <[email-masked]>
Date: Wed, 08 May 2024 13:53:41 +0000

> BTW the usage of `actions/cache` is causing certain steps to be skipped when they shouldn't be. For example, the "build postgresx86" step in [this run](https://github.com/postgresql-interfaces/psql…

I'm not sure how to handle that either. I guess we need to figure out how to invalidate the cache when the version of postgres changes as well.

Thanks for testing this

---

From: "apgrucza (@apgrucza)" <[email-masked]>
Date: Thu, 09 May 2024 01:21:13 +0000

> The dll's are installed in both places so it is currently correct.

Yes you are correct. So I guess the installers you built weren't working due to the caching issue.

---

From: "apgrucza (@apgrucza)" <[email-masked]>
Date: Thu, 09 May 2024 11:20:22 +0000

I disabled the caching in my fork so that I could test your changes. The x86 installer does now install the libssl and libcrypto DLLs. However, the DLL versions are not consistent between x86 and x64.

- **x86**: libpq.dll (17.0.0.0), libssl-3.dll (3.3.0.0)
- **x64**: libpq.dll (16.0.2.0), libssl-3-x64.dll (3.0.13.0)

Is it possible to build the x64 driver the same way as the x86 driver so that we can have some consistency? And to get the PostgreSQL code from a stable release, from https://www.postgresql.org/ftp/source/?

---

From: "davecramer (@davecramer)" <[email-masked]>
Date: Fri, 10 May 2024 15:56:25 +0000

Ah, good point. Yes, it is possible to build the driver the same way

---

From: "davecramer (@davecramer)" <[email-masked]>
Date: Fri, 10 May 2024 20:43:22 +0000

can you check these https://github.com/davecramer/psqlodbc/actions/runs/9036264469 ?

---

From: "apgrucza (@apgrucza)" <[email-masked]>
Date: Sat, 11 May 2024 03:06:46 +0000

I have a fix for the caching issue here: https://github.com/postgresql-interfaces/psqlodbc/pull/13

---

From: "apgrucza (@apgrucza)" <[email-masked]>
Date: Sat, 11 May 2024 03:22:06 +0000

> can you check these https://github.com/davecramer/psqlodbc/actions/runs/9036264469 ?

The x86 artifact still contains libpq 17, and looking at the GitHub Actions log reveals that it's because the "build postgresx86" step was again skipped (due to the caching problem). If you want to merge your changes then I can rebase #13 and the problem should go away.

---

From: "apgrucza (@apgrucza)" <[email-masked]>
Date: Sat, 11 May 2024 03:32:21 +0000

The EDB installer takes 2m 30s to install. With your recent change, is the EDB installer now only used to run PostgreSQL (so that the psqlodbc tests can run)? If so, we could reduce the workflow duration by running the PostgreSQL Docker image instead.

---

From: "davecramer (@davecramer)" <[email-masked]>
Date: Sat, 11 May 2024 11:25:40 +0000

> The EDB installer takes 2m 30s to install. With your recent change, is the EDB installer now only used to run PostgreSQL (so that the psqlodbc tests can run)? If so, we could reduce the workflow du…

I didn't think docker ran on github windows images ?

---

From: "apgrucza (@apgrucza)" <[email-masked]>
Date: Sat, 11 May 2024 11:32:44 +0000

> I didn't think docker ran on github windows images ?

Oh, that surprises me. I haven't used GitHub Actions much before.

---

From: "davecramer (@davecramer)" <[email-masked]>
Date: Sat, 11 May 2024 20:31:37 +0000

I think you can run testcontainers which does run docker but I don't think you can specify the version of postgres. It seemed simpler to use EDB