pgsql: Use pqsignal() in contrib programs rather than calling signal(2)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-committers(at)postgresql(dot)org
Subject: pgsql: Use pqsignal() in contrib programs rather than calling signal(2)
Date: 2013-03-17 20:09:54
Message-ID: E1UHJty-0006YM-4a@gemulon.postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

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.

Branch
------
master

Details
-------
http://git.postgresql.org/pg/commitdiff/3c07fbf40bd0276e4be02fc72cba6b1cd62da301

Modified Files
--------------
contrib/pg_standby/pg_standby.c | 8 ++++----
contrib/pg_test_fsync/pg_test_fsync.c | 8 ++++----
2 files changed, 8 insertions(+), 8 deletions(-)

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2013-03-18 02:42:30 pgsql: Improve signal-handler lockout mechanism in timeout.c.
Previous Message Tom Lane 2013-03-17 19:45:46 pgsql: initdb needs pqsignal() even on Windows.