Re: Cygwin cleanup

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: Cygwin cleanup
Дата
Msg-id CA+hUKGKnsKwF7x_=8gz2rMVRUxKijLJw7QPRvuXr=+XGxymY7g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Cygwin cleanup  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Cygwin cleanup  (Thomas Munro <thomas.munro@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Justin Kwan
Дата:
Сообщение: Re: Making pg_rewind faster
Следующее
От: Peter Smith
Дата:
Сообщение: Functions 'is_publishable_class' and 'is_publishable_relation' should stay together.