Re: Cygwin cleanup

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Justin Pryzby <pryzby(at)telsasoft(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Noah Misch <noah(at)leadboat(dot)com>
Subject: Re: Cygwin cleanup
Date: 2022-08-04 06:07:35
Message-ID: CA+hUKG+1O1QmfRtoBkdY+B6VifcoP_dzXynjMqpsX-wV6=UKpQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Aug 4, 2022 at 5:23 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Thomas Munro <thomas(dot)munro(at)gmail(dot)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...

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2022-08-04 06:24:56 Re: Race between KeepFileRestoredFromArchive() and restartpoint
Previous Message Kyotaro Horiguchi 2022-08-04 06:05:51 Re: Correct comment in RemoveNonParentXlogFiles()