Thread: Cygwin support
Last year the old Windows machine where I was running the buildfarm member lorikeet died, and since then we've had no buildfarm coverage for Cygwin. I now have a new (but slow) W11pro machine and I have been testing out Cygwin builds on it. I wanted to have it running the TAP tests, unlike lorikeet. Attached is a set of very small patches aimed at enabling this. The first patch makes us use our getopt implementation, just like we do in Mingw. meson.build already has this, so this would just be bringing configure into line with that. The second patch makes cygwin use the WIN32 pattern for psql's \watch command. Without that, the Unix style implementation hangs. The third patch make Cygwin skip a permissions test in the SSL tests, just like we do elsewhere in Windows. The fourth test ensures that we honor MAX_CONNECTIONS in a couple of places where we rerun the regression suite. MAX_CONNECTIONS was originally designed mainly for Cygwin, where too many concurrent connections cause issues. The fifth patch disables one of the pgbench tests which is unstable on Cygwin. There are still some issues, with the pg_dump, pg_upgrade, recovery and subscription test sets. But apart from that, with these patches I can consistently get a successful run. My intention is to apply these soon, and backpatch them as appropriate. These are all pretty low risk. I'm going to be away for a while starting in a day or so, but I'd like to get a buildfarm animal going with these before I disappear. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
Attachment
Hi Andrew, > Last year the old Windows machine where I was running the buildfarm > member lorikeet died, and since then we've had no buildfarm coverage for > Cygwin. I now have a new (but slow) W11pro machine and I have been > testing out Cygwin builds on it. I wanted to have it running the TAP > tests, unlike lorikeet. Attached is a set of very small patches aimed at > enabling this. > > [...] Thanks for the patches. I wonder though if it is advisable to support Cygwin if this requires extra effort from our side, compared to a regular Linux or Windows environment. I actually like the project but I wouldn't recommend running Postgres on prod, and for development these days it's simpler to use WSL / VirtualBox / Raspberry Pi, or running Postgres natively on Windows. -- Best regards, Aleksander Alekseev
On 2025-04-22 Tu 8:10 AM, Aleksander Alekseev wrote: > Hi Andrew, > >> Last year the old Windows machine where I was running the buildfarm >> member lorikeet died, and since then we've had no buildfarm coverage for >> Cygwin. I now have a new (but slow) W11pro machine and I have been >> testing out Cygwin builds on it. I wanted to have it running the TAP >> tests, unlike lorikeet. Attached is a set of very small patches aimed at >> enabling this. >> >> [...] > Thanks for the patches. > > I wonder though if it is advisable to support Cygwin if this requires > extra effort from our side, compared to a regular Linux or Windows > environment. I actually like the project but I wouldn't recommend > running Postgres on prod, and for development these days it's simpler > to use WSL / VirtualBox / Raspberry Pi, or running Postgres natively > on Windows. I agree that I would not normally use Cygwin to run a Postgres instance. But its psql is nicer than others on Windows because unlike the native builds we build it with readline. That's why I've kept a buildfarm animal going all these years. If the maintenance burden were high I wouldn't do so - but it's not really. And these patches are tiny. What I might do with the new animal is run just enough TAP tests to exercise psql. That would reduce the errors we get, so it would be less bother to anyone. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
Andrew Dunstan <andrew@dunslane.net> writes:
> I agree that I would not normally use Cygwin to run a Postgres instance.
> But its psql is nicer than others on Windows because unlike the native
> builds we build it with readline. That's why I've kept a buildfarm
> animal going all these years. If the maintenance burden were high I
> wouldn't do so - but it's not really. And these patches are tiny.
I vaguely recall some discussion about whether building with readline
has become possible under MSVC. I think it'd make a lot of people
happy if that could happen (but I hasten to add that I'm not
volunteering).
regards, tom lane
On 2025-04-22 Tu 10:26 AM, Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.net> writes: >> I agree that I would not normally use Cygwin to run a Postgres instance. >> But its psql is nicer than others on Windows because unlike the native >> builds we build it with readline. That's why I've kept a buildfarm >> animal going all these years. If the maintenance burden were high I >> wouldn't do so - but it's not really. And these patches are tiny. > I vaguely recall some discussion about whether building with readline > has become possible under MSVC. I think it'd make a lot of people > happy if that could happen (but I hasten to add that I'm not > volunteering). > > Neither am I, although I'll test it if somebody sends in a patch. If that happens I'll be happy enough to retire Cygwin support. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
On Tue, 2025-04-22 at 10:26 -0400, Tom Lane wrote: > I vaguely recall some discussion about whether building with readline > has become possible under MSVC. I think it'd make a lot of people > happy if that could happen (but I hasten to add that I'm not > volunteering). https://postgr.es/m/CACLU5mThm-uCtERMVHMoGED2EPfyS54j83WB20s_BmzVQuMkpg%40mail.gmail.com Seems like Kirk didn't pursue this further. Yours, Laurenz Albe
On 2025-04-22 Tu 12:55 PM, Laurenz Albe wrote:
On Tue, 2025-04-22 at 10:26 -0400, Tom Lane wrote:I vaguely recall some discussion about whether building with readline has become possible under MSVC. I think it'd make a lot of people happy if that could happen (but I hasten to add that I'm not volunteering).https://postgr.es/m/CACLU5mThm-uCtERMVHMoGED2EPfyS54j83WB20s_BmzVQuMkpg%40mail.gmail.com Seems like Kirk didn't pursue this further.
It's worth looking at, but I don't think it's possible for release 18 let alone the older releases. We should look at retiring Cygwin when all the live branches have psql with a working readline on native Windows builds.
cheers
andrew
-- Andrew Dunstan EDB: https://www.enterprisedb.com
On 2025-04-21 Mo 12:29 PM, Andrew Dunstan wrote: > > Last year the old Windows machine where I was running the buildfarm > member lorikeet died, and since then we've had no buildfarm coverage > for Cygwin. I now have a new (but slow) W11pro machine and I have been > testing out Cygwin builds on it. I wanted to have it running the TAP > tests, unlike lorikeet. Attached is a set of very small patches aimed > at enabling this. > > The first patch makes us use our getopt implementation, just like we > do in Mingw. meson.build already has this, so this would just be > bringing configure into line with that. > > The second patch makes cygwin use the WIN32 pattern for psql's \watch > command. Without that, the Unix style implementation hangs. > > The third patch make Cygwin skip a permissions test in the SSL tests, > just like we do elsewhere in Windows. > > The fourth test ensures that we honor MAX_CONNECTIONS in a couple of > places where we rerun the regression suite. MAX_CONNECTIONS was > originally designed mainly for Cygwin, where too many concurrent > connections cause issues. > > The fifth patch disables one of the pgbench tests which is unstable on > Cygwin. > > There are still some issues, with the pg_dump, pg_upgrade, recovery > and subscription test sets. But apart from that, with these patches I > can consistently get a successful run. > > My intention is to apply these soon, and backpatch them as > appropriate. These are all pretty low risk. I'm going to be away for a > while starting in a day or so, but I'd like to get a buildfarm animal > going with these before I disappear. > Time has got the better of me, I won't be able to get back to this for a couple of months. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
What are the economics of this? I used PostgreSQL and Cygwin 25 years ago and am amazed it is still a thing.
How much effort is it to support PostgreSQL on Cygwin?
How many actual users are using PostgreSQL on cygwin in production? (I should hope none!)
I would say it is something that should be announced as "deprecated" and see how many people complain, my bet no one will really care. Cygwin was a phenomenal hack in its day but I believe that those days have passed.
On Wed, Apr 23, 2025 at 3:56 PM Andrew Dunstan <andrew@dunslane.net> wrote:
On 2025-04-21 Mo 12:29 PM, Andrew Dunstan wrote:
>
> Last year the old Windows machine where I was running the buildfarm
> member lorikeet died, and since then we've had no buildfarm coverage
> for Cygwin. I now have a new (but slow) W11pro machine and I have been
> testing out Cygwin builds on it. I wanted to have it running the TAP
> tests, unlike lorikeet. Attached is a set of very small patches aimed
> at enabling this.
>
> The first patch makes us use our getopt implementation, just like we
> do in Mingw. meson.build already has this, so this would just be
> bringing configure into line with that.
>
> The second patch makes cygwin use the WIN32 pattern for psql's \watch
> command. Without that, the Unix style implementation hangs.
>
> The third patch make Cygwin skip a permissions test in the SSL tests,
> just like we do elsewhere in Windows.
>
> The fourth test ensures that we honor MAX_CONNECTIONS in a couple of
> places where we rerun the regression suite. MAX_CONNECTIONS was
> originally designed mainly for Cygwin, where too many concurrent
> connections cause issues.
>
> The fifth patch disables one of the pgbench tests which is unstable on
> Cygwin.
>
> There are still some issues, with the pg_dump, pg_upgrade, recovery
> and subscription test sets. But apart from that, with these patches I
> can consistently get a successful run.
>
> My intention is to apply these soon, and backpatch them as
> appropriate. These are all pretty low risk. I'm going to be away for a
> while starting in a day or so, but I'd like to get a buildfarm animal
> going with these before I disappear.
>
Time has got the better of me, I won't be able to get back to this for a
couple of months.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com