Re: convert libpgport's pqsignal() to a void function

On Thu, Jan 16, 2025 at 8:47 AM Nathan Bossart <nathandbossart(at)gmail(dot)com> wrote:
> On Thu, Jan 16, 2025 at 08:21:08AM +1300, Thomas Munro wrote:
> > Could be due to calling native signal() with a signal number other
> > than the 6 values required to work by the C standard?
>
> Looking closer, that probably makes more sense than my SIG_ERR redefinition
> theory. If that assertion is getting hit, that means signal() _is_
> returning SIG_ERR (either the system one or our redefined version), and it
> looks like it's pretty common to use -1 for SIG_ERR. That'd only affect
> Windows frontend programs, but it still sounds scary. I'll try getting
> more details about the error with some custom cfbot runs.

Windows barely has signals, so I don't think it's too scary... SIGINT
works but surprisingly runs the handler in another thread when you
press ^C, SIGABRT, SIGFPE, SIGSEGV presumably have the obvious
synchronous/exception-trapping implementations but we aren't even
trying to catch those*, and SIGTERM, SIGILL are pro forma, never
generated by the system. We've basically just invented more pro forma
ones that will also never be generated except in the backend's
entirely separate fake signal system that I hope to remove. +1 for
your idea of not defining them at all outside the backend, it's just
confusing noise.

The second surprising thing, unless you're an armchair Unix
archeologist, is that all but SIGFPE revert to SIG_DFL when they fire,
like POSIX's SA_RESETHAND mode. I don't know if it also has
SA_NODEFER behaviour (a combination of behaviours seen in some old
Unixen of yestermillennium: your handler had to keep reinstalling
itself, cf initdb.c:trapsig, but for a brief window the default
process-terminating-core-dumping-nasal-daemon behaviour was installed
and there was nothing you could do about that race; the BSD crew fixed
that mistake a long time ago, everyone does it that way now, and POSIX
sigaction() made those policies explicit and is the recommended
replacement, but to this day the C standard has just signal() with
undefined semantics and no requirement that any of it even work).

*Even in the backend we don't catch Windows' native SIGFPE AFAICS, so
I guess those must exit instead of being converted to an ERROR by
FloatExceptionHandler. I wonder if there is a way to reach that
condition from a SQL query.