Use pqsignal() in contrib programs rather than calling signal(2) directly.

The semantics of signal(2) are more variable than one could wish; in
particular, on strict-POSIX platforms the signal handler will be reset
to SIG_DFL when the signal is delivered.  This demonstrably breaks
pg_test_fsync's use of SIGALRM.  The other changes I made are not
absolutely necessary today, because the called handlers all exit the
program anyway.  But it seems like a good general practice to use
pqsignal() exclusively in Postgres code, now that we have it available
everywhere.

1 files changed, 4 insertions, 4 deletions

diff --git a/contrib/pg_test_fsync/pg_test_fsync.c b/contrib/pg_test_fsync/pg_test_fsync.c
index 5ee03981a3b..7bc0d0e5fd9 100644
--- a/contrib/pg_test_fsync/pg_test_fsync.c
+++ b/contrib/pg_test_fsync/pg_test_fsync.c
@@ -101,14 +101,14 @@ main(int argc, char *argv[])
 	handle_args(argc, argv);
 
 	/* Prevent leaving behind the test file */
-	signal(SIGINT, signal_cleanup);
-	signal(SIGTERM, signal_cleanup);
+	pqsignal(SIGINT, signal_cleanup);
+	pqsignal(SIGTERM, signal_cleanup);
 #ifndef WIN32
-	signal(SIGALRM, process_alarm);
+	pqsignal(SIGALRM, process_alarm);
 #endif
 #ifdef SIGHUP
 	/* Not defined on win32 */
-	signal(SIGHUP, signal_cleanup);
+	pqsignal(SIGHUP, signal_cleanup);
 #endif
 
 	prepare_buf();