diff options
author | Nathan Bossart <nathan@postgresql.org> | 2025-01-16 15:56:39 -0600 |
---|---|---|
committer | Nathan Bossart <nathan@postgresql.org> | 2025-01-16 15:56:39 -0600 |
commit | 5cda4fdb0beb64453b634d0ab966912965c7b8f6 (patch) | |
tree | 8f7ac33e1f9ca5517bf7cb45d317f4d9e443c2a0 /src/backend/parser/parse_oper.c | |
parent | d7674c9fab09d5bab427ba3b9b7a20b169aba715 (diff) | |
download | postgresql-5cda4fdb0beb64453b634d0ab966912965c7b8f6.tar.gz postgresql-5cda4fdb0beb64453b634d0ab966912965c7b8f6.zip |
Avoid calling pqsignal() with invalid signals on Windows frontends.
As noted by the comment at the top of port/pqsignal.c, Windows
frontend programs can only use pqsignal() with the 6 signals
required by C. Most places avoid using invalid signals via #ifndef
WIN32, but initdb and pg_test_fsync check whether the signal itself
is defined, which doesn't work because win32_port.h defines many
extra signals for the signal emulation code. pg_regress seems to
have missed the memo completely. These issues aren't causing any
real problems today because nobody checks the return value of
pqsignal(), but a follow-up commit will add some error checking.
To fix, surround all frontend calls to pqsignal() that use signals
that are invalid on Windows with #ifndef WIN32. We cannot simply
skip defining the extra signals in win32_port.h for frontends
because they are needed in places such as pgkill().
Reviewed-by: Thomas Munro
Discussion: https://postgr.es/m/Z4chOKfnthRH71mw%40nathan
Diffstat (limited to 'src/backend/parser/parse_oper.c')
0 files changed, 0 insertions, 0 deletions