Thread: Porting PG Extension from UNIX to Windows

On 04/25/2018 04:45 AM, insaf.k wrote:
> Hello,
>
> I have developed a postgres extension in Linux. I want to compile it
> in MS Windows as well. 
>
> The extension extensively make use of POSIX threads and mutexes.
>
> I've done some research regarding compiling in Windows. I am not sure
> in what way I should compile the extension. AFAIK, Visual Studio is
> not POSIX compliant and so I'll have to rewrite all those POSIX calls
> using Windows API. So it's better to compile the extension in Cygwin.
>
> I have some questions regarding compiling the extension in Cygwin. Do
> I have to build PG in Cygwin, if I want to compile the extension in
> Cygwin?
>
> Our deployment pattern is like this, build everything in one machine
> and copy the DLLs into the production machine. So, if I compile in
> Cygwin, will the generated DLLs work in other Windows machines? Would
> the target machine be required to install any dependencies related to
> Cygwin in order to use the DLLs?
>
> Also, one more question, not related to PG. Cygwin vs native Windows
> API calls, will there be much difference in the performance?(We are
> not using fork() calls, btw).
>
>
>
>



Performance of postgres under Cygwin is significantly worse than under
native Windows. Unless you're already using Cygwin my advice would be to
stay away from it.

You would probably be better off building with Mingw/Msys (see our docs
for details). It's also possible to use Cmake for extensions, although
this is currently not well documented.

w.r.t. threads and mutexes, you would probably be better off using the
Windows API.  See for example what is said here regarding windows
threads vs posix threads: <https://wiki.qt.io/MinGW-64-bit>

cheers

andrew


-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Greetings, insaf.k.

You wrote 25.04.2018, 11:45:

> Hello,



> I have developed a postgres extension in Linux. I want to compile it in MS Windows as well.

You should try MSYS2. It's far better than VS and MSYS right now.

I may try to build your extension if you want.



> The extension extensively make use of POSIX threads and mutexes.



> I've done some research regarding compiling in Windows. I am not
> sure in what way I should compile the extension. AFAIK, Visual
> Studio is not POSIX compliant and so I'll have to rewrite all those
> POSIX calls using Windows API. So it's better to compile the extension in Cygwin.



> I have some questions regarding compiling the extension in Cygwin.
> Do I have to build PG in Cygwin, if I want to compile the extension in Cygwin?



> Our deployment pattern is like this, build everything in one
> machine and copy the DLLs into the production machine. So, if I
> compile in Cygwin, will the generated DLLs work in other Windows
> machines? Would the target machine be required to install any
> dependencies related to Cygwin in order to use the DLLs?



> Also, one more question, not related to PG. Cygwin vs native
> Windows API calls, will there be much difference in the
> performance?(We are not using fork() calls, btw).





> Thanks,

> Insaf



-- 
Kind regards,
 Pavlo                          mailto:pavlo.golub@cybertec.at

On 25 April 2018 at 16:45, insaf.k <insaf.k@zohocorp.com> wrote:
> Hello,
>
> I have developed a postgres extension in Linux. I want to compile it in MS
> Windows as well.
>
> The extension extensively make use of POSIX threads and mutexes.
>
> I've done some research regarding compiling in Windows. I am not sure in
> what way I should compile the extension. AFAIK, Visual Studio is not POSIX
> compliant and so I'll have to rewrite all those POSIX calls using Windows
> API. So it's better to compile the extension in Cygwin.
>
> I have some questions regarding compiling the extension in Cygwin. Do I have
> to build PG in Cygwin, if I want to compile the extension in Cygwin?

If you want to compile the extension in cygwin with the cygwin
compiler, to get support for native(ish) pthreads, etc, then yes you
must use a PostgreSQL that is also for cygwin.

You can compile with mingw within cygwin - after all, msys is
basically a cut down cygwin. That produces a native Windows
executable, though it might still need mingw's runtime library, I
don't remember. You might as well use msys in that case, though. I
don't know what the state of pthreads support in mingw is.

> Our deployment pattern is like this, build everything in one machine and
> copy the DLLs into the production machine. So, if I compile in Cygwin, will
> the generated DLLs work in other Windows machines?

Only if they have a compatible cygwin AND a cygwin postgres.

> Would the target machine
> be required to install any dependencies related to Cygwin in order to use
> the DLLs?

Yes.

> Also, one more question, not related to PG. Cygwin vs native Windows API
> calls, will there be much difference in the performance?(We are not using
> fork() calls, btw).

Yes, Cygwin was significantly slower last I checked.

You might be able to run Pg under Windows Subsystem for Linux, using a
Linux PostgreSQL and a pthreads build of your extension.

Personally, I think you'll have to face adapting your threading layer.
But another option might be to use mingw64's threading support; see
the "POSIX Threads for Windows" section of
https://en.wikipedia.org/wiki/POSIX_Threads

-- 
 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

I've done some research regarding compiling in Windows. I am not sure in what way I should compile the extension. AFAIK, Visual Studio is not POSIX compliant and so I'll have to rewrite all those POSIX calls using Windows API. So it's better to compile the extension in Cygwin.

I have some questions regarding compiling the extension in Cygwin. Do I have to build PG in Cygwin, if I want to compile the extension in Cygwin?

I think it might depend on the extension, but we have managed to use mingw-compiled extension with VS-compiled PG. Please look at the demo script:
https://pastebin.com/3jQahYNe
If you have any questions, please don't hesitate to ask.

Best regards,

------
Alexander Lakhin
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

Greetings, Alexander.

You wrote 08.05.2018, 9:42:

> 25.04.2018 11:45, insaf.k wrote:

>   
> I've         done some research regarding compiling in Windows. I
> am not sure         in what way I should compile the extension.
> AFAIK, Visual Studio         is not POSIX compliant and so I'll have
> to rewrite all those         POSIX calls using Windows API. So it's
> better to compile the         extension in Cygwin.
>   

>     
> I have some questions regarding compiling the extension in         
> Cygwin. Do I have to build PG in Cygwin, if I want to compile        the extension in Cygwin?
>       
>      I think it might depend on the extension, but we have managed
> to use     mingw-compiled extension with VS-compiled PG. Please look at the     demo script:
>   https://pastebin.com/3jQahYNe
>      If you have any questions, please don't hesitate to ask.

Cool idea.

- Why are you using x86 version of MSYS2?
- And why don't you use just msys2-x86_64-latest.tar.xz instead of
exactly named one?

>   
>   Best         regards,
>     
>  ------ 
>            Alexander Lakhin 
>            Postgres Professional: http://www.postgrespro.com  
>            The Russian Postgres Company
>   



-- 
Kind regards,
 Pavlo                          mailto:pavlo.golub@cybertec.at

Cool idea.

- Why are you using x86 version of MSYS2?

We build PostgresPro for x86 and x64 so I choose to use x86 version as a common denominator to run the same script in 32-bit Windows.
(When running on 64-bit Windows any (x86/x64) version of PostgresPro could be installed so the target host determined by the installed postgres.exe bitness.)

- And why don't you use just msys2-x86_64-latest.tar.xz instead of
exactly named one?

I don't remember whether I tried and had troubles with the 'latest', but I prefer to use some fixed version and move to a newer one in a controlled manner.

Best regards,

------
Alexander Lakhin
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company