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