Re: Cygwin cleanup - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Cygwin cleanup
Date
Msg-id CA+hUKG+1O1QmfRtoBkdY+B6VifcoP_dzXynjMqpsX-wV6=UKpQ@mail.gmail.com
Whole thread Raw
In response to Re: Cygwin cleanup  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, Aug 4, 2022 at 5:23 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Thomas Munro <thomas.munro@gmail.com> writes:
> > It may be madness to try to work around this, but I wonder if we could
> > use a static local variable that we update with atomic compare
> > exhange, inside PG_SIGNAL_HANDLER_ENTRY(), and
> > PG_SIGNAL_HANDLER_EXIT() macros that do nothing on every other system.
> > On entry, if you can do 0->1 it means you are allowed to run the
> > function.  If it's non-zero, set n->n+1 and return immediately: signal
> > blocked, but queued for later.  On exit, you CAS n->0.  If n was > 1,
> > then you have to jump back to the top and run the function body again.
>
> And ... we're expending all this effort for what exactly?

I'd be almost as happy if we ripped it all out, shut down lorikeet and
added it to the list of fallen platforms.  I'd feel a bit like a
vandal, though.  My suggestion is a last-ditch idea for Noah (CCd)
and/or Andrew to consider, who (respectively) blocked this last time
and run lorikeet.  No plans to write that patch myself...



pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: Correct comment in RemoveNonParentXlogFiles()
Next
From: Noah Misch
Date:
Subject: Re: Race between KeepFileRestoredFromArchive() and restartpoint