Re: Cygwin cleanup - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Cygwin cleanup
Date
Msg-id CA+hUKGKnsKwF7x_=8gz2rMVRUxKijLJw7QPRvuXr=+XGxymY7g@mail.gmail.com
Whole thread Raw
In response to Re: Cygwin cleanup  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Cygwin cleanup
List pgsql-hackers
On Wed, Jul 27, 2022 at 5:09 AM Robert Haas <robertmhaas@gmail.com> wrote:
> On Tue, Jul 26, 2022 at 7:40 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > I think maybe we should re-open the discussion.  I've certainly
> > reached the stage of fed-up-ness.  That platform seems seriously
> > broken, upstream is making no progress on fixing it, and there
> > doesn't seem to be any real-world use-case.  The only positive
> > argument for it is that Readline doesn't work in the other
> > Windows builds --- but we've apparently not rechecked that
> > statement in eighteen years, so maybe things are better now.
> >
> > If we could just continue to blithely ignore lorikeet's failures,
> > I wouldn't mind so much; but doing any significant amount of new
> > code development work for the platform seems like throwing away
> > developer time.
>
> I agree with that. All things being equal, I like the idea of
> supporting a bunch of different platforms, and Cygwin doesn't really
> look that dead. It has recent releases. But if blocking signals
> doesn't actually work on that platform, making PostgreSQL work
> reliably there seems really difficult.

It's one thing to drop old dead Unixes but I don't think anyone would
enjoy dropping support for an active open source project.  The best
outcome would be for people who have an interest in seeing PostgreSQL
work correctly on Cygwin to help get the bug fixed.  Here are the
threads I'm aware of:

https://cygwin.com/pipermail/cygwin/2017-August/234001.html
https://cygwin.com/pipermail/cygwin/2017-August/234097.html

I wonder if these problems would go away as a nice incidental
side-effect if we used latches for postmaster wakeups.  I don't
know... maybe, if the problem is just with the postmaster's pattern of
blocking/unblocking?  Maybe backend startup is simple enough that it
doesn't hit the bug?  From a quick glance, I think the assertion
failures that occur in regular backends can possibly be blamed on the
postmaster getting confused about its children due to unexpected
handler re-entry.



pgsql-hackers by date:

Previous
From: Justin Kwan
Date:
Subject: Re: Making pg_rewind faster
Next
From: Peter Smith
Date:
Subject: Functions 'is_publishable_class' and 'is_publishable_relation' should stay together.