Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tXtPH-00Fyo5-03 for pgsql-hackers@arkaria.postgresql.org; Wed, 15 Jan 2025 02:45:23 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tXtPD-006AVy-Mi for pgsql-hackers@arkaria.postgresql.org; Wed, 15 Jan 2025 02:45:20 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tXtPD-006AVp-Bj for pgsql-hackers@lists.postgresql.org; Wed, 15 Jan 2025 02:45:19 +0000 Received: from mail-il1-x12b.google.com ([2607:f8b0:4864:20::12b]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tXtPB-000TYM-1M for pgsql-hackers@lists.postgresql.org; Wed, 15 Jan 2025 02:45:19 +0000 Received: by mail-il1-x12b.google.com with SMTP id e9e14a558f8ab-3ce87d31480so268345ab.2 for ; Tue, 14 Jan 2025 18:45:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736909116; x=1737513916; darn=lists.postgresql.org; h=content-disposition:mime-version:message-id:subject:cc:to:from:date :from:to:cc:subject:date:message-id:reply-to; bh=uVguaiWBux8/yT0QvoagTeQi1QJQGIVAccqLOUuFBpA=; b=JAeSTauAujGj8flLeQJqzC8b79eVf9eaVY416R1TcIg81Xj84u1Iq/uL3j7Yq5JMdk Qqx6n7cwovLljHAhTQz5er2ZozZpPkyITGfdDjY5BFK94YWPbmqd2oGzSADJVY0bm+KG K6jUAdeNZcB1PS5W4RcynaEAT19RGIQDeZZPT2jNduqwCAvjLYcQYo1Fi+ZlcJ2epSkX h9u3hdNQkZ5tNFvuR9wGz7RtO4U0EHv1ZYiMsQXKWaAx0Ridg14f0zI7580DPyNpU2Fe u1Tk27Xag9GAAc+xYp8zYU+5u23nf+S22PBVhTSdoou1A5UxMasbhtIjPl4/44mBxfAv vR0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736909116; x=1737513916; h=content-disposition:mime-version:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=uVguaiWBux8/yT0QvoagTeQi1QJQGIVAccqLOUuFBpA=; b=HArBh7mYw6c2EI7AvEkqm0OZpn1PECY3TMRxnoRmx1Dgs4u5udomYBoLrE2LYkN0hm Rk+rfavXQ+7FqQL+YzrF+O0s6Op/un6z7leotv4u2o8p6xATlOiao3TkovMH2iSoBrFt vSVTxo8pUrUX0yjTA0o/gcl1Hzj7SVcTms/mDZjqvsbykKGOep87KAcWGGTqHY1JhDsZ ZqiOmsvq+MES25Vss+LV6pSai/1tfWL5k7EwgTspfh2A2f290cCVincpZ60vZCbqJNZI XFRPawcyhTvn4H6tyyjMAxjwfhRgFqhGoSATnCBKTZbMpjQkn99xfaYBKVEKZlu9WLQ+ bLCw== X-Forwarded-Encrypted: i=1; AJvYcCWpTylrEtb7qVDyNVFqhVge+40ucrXdtxX8cAUvOta+zPiykFIiUdSiozN+s6HHmdMGC8h15yCOeeljA3vv@lists.postgresql.org X-Gm-Message-State: AOJu0YxMvUJwoSUWnrx23ouqJpNEQc3dilkRXdOoQzD9M9vbd+Ka9sQv 5ofC4AO+ZS8/DfDH9j8z3bA6pesnUkM6ZADHZ7xJxrIzLRVzrvHu X-Gm-Gg: ASbGncuwCiZahcpT2FMWvx9zyYIXn5RLEgpoTIInz9p/e0Nu4d5SLpai95qJ+ew8l+T kN+LCx/7cqElhHSoOnIwPfbNHPKEJmIjtZeu3uK2XDsYC2kApCDeKklnZuF/cfAhy1kpyxlW7mV CyawK/PszNcZwDnylqI1ZdqMNlVOArPQjLWQA+wp+o738Ja5U/ED4JdInwHT+RBtSdfw1qFI4Uh IJmdV+gvCn0nzve1/35ZzRKBN/tM27dWfm1v/bCqIGB3HWJMW4BbernYpZg+KGSAUQXmNC2qd1d ej8AVYLQmuC5eEhBUHoDUgByE7W9gAF4hDYQwo5EhxVuOJw= X-Google-Smtp-Source: AGHT+IFMRuaeyuM0HdjHfYSB6/MchjqTaDkD5btIFfjp0gFdIa8+83zPgoi99mA2bVav8DK+q569Yg== X-Received: by 2002:a92:1905:0:b0:3a7:820c:180a with SMTP id e9e14a558f8ab-3ce3a8bb656mr161330205ab.19.1736909115651; Tue, 14 Jan 2025 18:45:15 -0800 (PST) Received: from nathan (162-195-168-172.lightspeed.stlsmo.sbcglobal.net. [162.195.168.172]) by smtp.gmail.com with ESMTPSA id 8926c6da1cb9f-4ea1b719634sm3769146173.107.2025.01.14.18.45.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Jan 2025 18:45:14 -0800 (PST) Date: Tue, 14 Jan 2025 20:45:12 -0600 From: Nathan Bossart To: Tom Lane Cc: Fujii Masao , Andy Fan , pgsql-hackers@lists.postgresql.org Subject: convert libpgport's pqsignal() to a void function Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nPoskaipmpboFwE3" Content-Disposition: inline List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --nPoskaipmpboFwE3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline (moving to a new thread) On Mon, Jan 13, 2025 at 10:04:31AM -0600, Nathan Bossart wrote: > On Sat, Jan 11, 2025 at 02:04:13PM -0500, Tom Lane wrote: >> BTW, this decouples legacy-pqsignal.c from pqsignal.c enough >> that we could now do what's contemplated in the comments from >> 3b00fdba9: simplify that version by making it return void, >> or perhaps better just a true/false success report. >> I've not touched that point here, though. > > I think it should just return void since AFAICT nobody checks the return > value. But it would probably be a good idea to add some sort of error > checking within the function. I've attached a draft patch that adds some > new assertions. I originally tried to use elog() where it was available, > but besides making the code even more unreadable, I think it's unnecessary > (since AFAICT any problems are likely coding errors). With commit 9a45a89 in place, this is now possible. I've attached a new version of the patch with a more fleshed-out commit message and a small comment fix. For background, the protections added by commit 3b00fdb introduced race conditions to pqsignal() that could lead to bogus return values. That's of little consequence since nobody seems to look at the return values, but it would have been nice to convert it to a void function to avoid any possibility of a bogus return value. Unfortunately, doing so would have required also modifying legacy-pqsignal.c's version of the function, which would've required an SONAME bump, which didn't seem worth it. Or so I thought... Thanks to commit 9a45a89, legacy-pqsignal.c now has its own dedicated extern for pqsignal(), which decouples it enough that we can follow through with changing libpqport's pqsignal() to a void function. Thoughts? -- nathan --nPoskaipmpboFwE3 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="v2-0001-Convert-libpgport-s-pqsignal-to-a-void-function.patch" From 7b6e061be774d05d888bc5eac20e9aa09fc75403 Mon Sep 17 00:00:00 2001 From: Nathan Bossart Date: Tue, 14 Jan 2025 20:34:10 -0600 Subject: [PATCH v2 1/1] Convert libpgport's pqsignal() to a void function. The protections added by commit 3b00fdba9f introduced race conditions to this function that can lead to bogus return values. Since nobody seems to inspect the return value, this is of little consequence, but it would have been nice to convert it to a void function to avoid any possibility of a bogus return value. Unfortunately, doing so would have required also modifying legacy-pqsignal.c's version of the function, which would've required an SONAME bump. Or so I thought... Thanks to commit 9a45a89c38, legacy-pqsignal.c now has its own dedicated extern for pqsignal(), which decouples it enough that we can follow through with changing libpgport's pqsignal() to a void function. This commit also adds a bit of error checking in the form of assertions for the return value of sigaction()/signal(). Since a failure most likely indicates a coding error, and nobody has ever bothered to check pqsignal()'s return value, it's probably not worth doing anything fancier. --- src/include/port.h | 2 +- src/port/pqsignal.c | 34 ++++++---------------------------- 2 files changed, 7 insertions(+), 29 deletions(-) diff --git a/src/include/port.h b/src/include/port.h index f0e28ce5c53..4e9e5657872 100644 --- a/src/include/port.h +++ b/src/include/port.h @@ -520,7 +520,7 @@ extern int pg_mkdir_p(char *path, int omode); #define pqsignal pqsignal_be #endif typedef void (*pqsigfunc) (SIGNAL_ARGS); -extern pqsigfunc pqsignal(int signo, pqsigfunc func); +extern void pqsignal(int signo, pqsigfunc func); /* port/quotes.c */ extern char *escape_single_quotes_ascii(const char *src); diff --git a/src/port/pqsignal.c b/src/port/pqsignal.c index 1169de6b81e..5dd8b76bae8 100644 --- a/src/port/pqsignal.c +++ b/src/port/pqsignal.c @@ -112,31 +112,15 @@ wrapper_handler(SIGNAL_ARGS) /* * Set up a signal handler, with SA_RESTART, for signal "signo" * - * Returns the previous handler. - * - * NB: If called within a signal handler, race conditions may lead to bogus - * return values. You should either avoid calling this within signal handlers - * or ignore the return value. - * - * XXX: Since no in-tree callers use the return value, and there is little - * reason to do so, it would be nice if we could convert this to a void - * function instead of providing potentially-bogus return values. - * Unfortunately, that requires modifying the pqsignal() in legacy-pqsignal.c, - * which in turn requires an SONAME bump, which is probably not worth it. - * * Note: the actual name of this function is either pqsignal_fe when * compiled with -DFRONTEND, or pqsignal_be when compiled without that. * This is to avoid a name collision with libpq's legacy-pqsignal.c. */ -pqsigfunc +void pqsignal(int signo, pqsigfunc func) { - pqsigfunc orig_func = pqsignal_handlers[signo]; /* assumed atomic */ #if !(defined(WIN32) && defined(FRONTEND)) - struct sigaction act, - oact; -#else - pqsigfunc ret; + struct sigaction act; #endif Assert(signo < PG_NSIG); @@ -155,17 +139,11 @@ pqsignal(int signo, pqsigfunc func) if (signo == SIGCHLD) act.sa_flags |= SA_NOCLDSTOP; #endif - if (sigaction(signo, &act, &oact) < 0) - return SIG_ERR; - else if (oact.sa_handler == wrapper_handler) - return orig_func; - else - return oact.sa_handler; + if (sigaction(signo, &act, NULL) < 0) + Assert(false); /* probably indicates coding error */ #else /* Forward to Windows native signal system. */ - if ((ret = signal(signo, func)) == wrapper_handler) - return orig_func; - else - return ret; + if (signal(signo, func) == SIG_ERR) + Assert(false); /* probably indicates coding error */ #endif } -- 2.39.5 (Apple Git-154) --nPoskaipmpboFwE3--