aboutsummaryrefslogtreecommitdiff
path: root/src/backend/parser/parse_oper.c
diff options
context:
space:
mode:
authorNathan Bossart <nathan@postgresql.org>2025-01-16 15:56:39 -0600
committerNathan Bossart <nathan@postgresql.org>2025-01-16 15:56:39 -0600
commit5cda4fdb0beb64453b634d0ab966912965c7b8f6 (patch)
tree8f7ac33e1f9ca5517bf7cb45d317f4d9e443c2a0 /src/backend/parser/parse_oper.c
parentd7674c9fab09d5bab427ba3b9b7a20b169aba715 (diff)
downloadpostgresql-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