Re: Cygwin cleanup

On Thu, Aug 4, 2022 at 4:16 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> On Thu, Aug 4, 2022 at 3:38 PM Justin Pryzby <pryzby(at)telsasoft(dot)com> wrote:
> > [train wreck]
>
> Oh my, so I'm getting the impression we might actually be totally
> unstable on Cygwin. Which surprises me because ... wait a minute ...
> lorikeet isn't even running most of the tests. So... we don't really
> know the degree to which any of this works at all?

Hmm, it's possible that all these failures are just new-to-me effects
of the known bug. Certainly the assertion failures are of the usual
type, and I think it might be possible for the weird parallel query
failure to be explained by the postmaster forking extra phantom child
processes.

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.