Cygwin support

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).

/messages/by-id/CACLU5mThm-uCtERMVHMoGED2EPfyS54j83WB20s_BmzVQuMkpg@mail.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).

/messages/by-id/CACLU5mThm-uCtERMVHMoGED2EPfyS54j83WB20s_BmzVQuMkpg@mail.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-28 Mo 4:53 PM, Mark Woodward wrote:

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.

Please don't top-post on PostgreSQL lists.

I don't see it as our role to pass judgements like this on what people
use. While Cygwin exists it's not our province to deprecate its use. If
the maintenance effort were onerous I might be willing to relook at our
support for it, but the simple answer to your first question is that the
maintenance effort is close to zero. As I pointed out elsewhere in this
thread, even if the server has limited use, the Cygwin psql client is
nicer to use on Windows than the native build, reason enough to keep it
going, at least until we improve the native build.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

On Tue, May 27, 2025 at 10:53:55AM -0400, Andrew Dunstan wrote:

On 2025-04-28 Mo 4:53 PM, Mark Woodward wrote:

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.

Please don't top-post on PostgreSQL lists.

I don't see it as our role to pass judgements like this on what people use.
While Cygwin exists it's not our province to deprecate its use. If the
maintenance effort were onerous I might be willing to relook at our support
for it, but the simple answer to your first question is that the maintenance
effort is close to zero. As I pointed out elsewhere in this thread, even if
the server has limited use, the Cygwin psql client is nicer to use on
Windows than the native build, reason enough to keep it going, at least
until we improve the native build.

cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com

+1

I also have known of environments where Cygwin was an allowed
application and native Windows applications were severely restricted. Go
figure.

Regards,
Ken

On Tue, Apr 22, 2025 at 12:55 PM Laurenz Albe <laurenz.albe@cybertec.at>
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).

/messages/by-id/CACLU5mThm-uCtERMVHMoGED2EPfyS54j83WB20s_BmzVQuMkpg@mail.gmail.com

Seems like Kirk didn't pursue this further.

Laurenz, I was a bit early and the new build system and properly
understanding how to link this in got in the way.
As feedback, there are a lot of rough edges with readline() under windows.
(I've switched to WSL which is Ubuntu,
and tab completion works).

Since our big PG client went live, I will queue this up to take a peek at
it again. (They already fixed the GIANT if/then
condition that was breaking the MSVC build that the auto-complete was
using).
I believe the other 2-3 issues I had was where the system looks for the
"configuration" files for readline.
And the feedback was clear: We cannot modify the readline source. We must
use it as published.

I also thought one of the build guys said readline "might" come along for
the ride with the newer build...

Thanks for the reminder, this is back en queue for me to look at.

Since this thread discussed possibly bringing back Cygwin buildfarm
coverage, you might be interested in this proposed change:

/messages/by-id/CA+hUKG+BpW=KhGHTWGMe0cSETMYZsSygv5jFWD1Y6wcbAn2ecQ@mail.gmail.com

On 2025-11-23 Su 6:44 PM, Thomas Munro wrote:

Since this thread discussed possibly bringing back Cygwin buildfarm
coverage, you might be interested in this proposed change:

/messages/by-id/CA+hUKG+BpW=KhGHTWGMe0cSETMYZsSygv5jFWD1Y6wcbAn2ecQ@mail.gmail.com

Well, I was going to look at reviving a Cygwin animal over the end of
year break. I have a machine available for it. I have no idea if Cygwin
even still has the issue ... let me see.

cheers

andrew

--
Andrew Dunstan
EDB:https://www.enterprisedb.com