rdelaage/postgresql
1
0
Fork 0
mirror of https://git.postgresql.org/git/postgresql.git synced 2024-09-07 10:39:20 +02:00
Code Issues Packages Projects Releases Wiki Activity
054e8c6cdb
postgresql/src/port/pqsignal.c

91 lines
2.2 KiB
C
Raw Normal View History

Move pqsignal() to libpgport. We had two copies of this function in the backend and libpq, which was already pretty bogus, but it turns out that we need it in some other programs that don't use libpq (such as pg_test_fsync). So put it where it probably should have been all along. The signal-mask-initialization support in src/backend/libpq/pqsignal.c stays where it is, though, since we only need that in the backend.
2013-03-17 17:06:42 +01:00
/*-------------------------------------------------------------------------
*
* pqsignal.c
* reliable BSD-style signal(2) routine stolen from RWW who stole it
* from Stevens...
*
Update copyright for 2018 Backpatch-through: certain files through 9.3
2018-01-03 05:30:12 +01:00
* Portions Copyright (c) 1996-2018, PostgreSQL Global Development Group
Move pqsignal() to libpgport. We had two copies of this function in the backend and libpq, which was already pretty bogus, but it turns out that we need it in some other programs that don't use libpq (such as pg_test_fsync). So put it where it probably should have been all along. The signal-mask-initialization support in src/backend/libpq/pqsignal.c stays where it is, though, since we only need that in the backend.
2013-03-17 17:06:42 +01:00
* Portions Copyright (c) 1994, Regents of the University of California
*
*
* IDENTIFICATION
* src/port/pqsignal.c
*
Remove support for Unix systems without the POSIX signal APIs. Remove configure's checks for HAVE_POSIX_SIGNALS, HAVE_SIGPROCMASK, and HAVE_SIGSETJMP. These APIs are required by the Single Unix Spec v2 (POSIX 1997), which we generally consider to define our minimum required set of Unix APIs. Moreover, no buildfarm member has reported not having them since 2012 or before, which means that even if the code is still live somewhere, it's untested --- and we've made plenty of signal-handling changes of late. So just take these APIs as given and save the cycles for configure probes for them. However, we can't remove as much C code as I'd hoped, because the Windows port evidently still uses the non-POSIX code paths for signal masking. Since we're largely emulating these BSD-style APIs for Windows anyway, it might be a good thing to switch over to POSIX-like notation and thereby remove a few more #ifdefs. But I'm not in a position to code or test that. In the meantime, we can at least make things a bit more transparent by testing for WIN32 explicitly in these places.
2015-08-31 18:55:59 +02:00
* We now assume that all Unix-oid systems have POSIX sigaction(2)
* with support for restartable signals (SA_RESTART). We used to also
* support BSD-style signal(2), but there really shouldn't be anything
* out there anymore that doesn't have the POSIX API.
Move pqsignal() to libpgport. We had two copies of this function in the backend and libpq, which was already pretty bogus, but it turns out that we need it in some other programs that don't use libpq (such as pg_test_fsync). So put it where it probably should have been all along. The signal-mask-initialization support in src/backend/libpq/pqsignal.c stays where it is, though, since we only need that in the backend.
2013-03-17 17:06:42 +01:00
*
initdb needs pqsignal() even on Windows. I had thought we weren't using this version of pqsignal() at all on Windows, but that's wrong --- initdb is using it (and coping with the POSIX-ish semantics of bare signal() :-(). So allow the file to be built in WIN32+FRONTEND case, and add it to the MSVC build logic.
2013-03-17 20:19:47 +01:00
* Windows, of course, is resolutely in a class by itself. In the backend,
* we don't use this file at all; src/backend/port/win32/signal.c provides
* pqsignal() for the backend environment. Frontend programs can use
Remove support for Unix systems without the POSIX signal APIs. Remove configure's checks for HAVE_POSIX_SIGNALS, HAVE_SIGPROCMASK, and HAVE_SIGSETJMP. These APIs are required by the Single Unix Spec v2 (POSIX 1997), which we generally consider to define our minimum required set of Unix APIs. Moreover, no buildfarm member has reported not having them since 2012 or before, which means that even if the code is still live somewhere, it's untested --- and we've made plenty of signal-handling changes of late. So just take these APIs as given and save the cycles for configure probes for them. However, we can't remove as much C code as I'd hoped, because the Windows port evidently still uses the non-POSIX code paths for signal masking. Since we're largely emulating these BSD-style APIs for Windows anyway, it might be a good thing to switch over to POSIX-like notation and thereby remove a few more #ifdefs. But I'm not in a position to code or test that. In the meantime, we can at least make things a bit more transparent by testing for WIN32 explicitly in these places.
2015-08-31 18:55:59 +02:00
* this version of pqsignal() if they wish, but beware that this does
* not provide restartable signals on Windows.
*
Move pqsignal() to libpgport. We had two copies of this function in the backend and libpq, which was already pretty bogus, but it turns out that we need it in some other programs that don't use libpq (such as pg_test_fsync). So put it where it probably should have been all along. The signal-mask-initialization support in src/backend/libpq/pqsignal.c stays where it is, though, since we only need that in the backend.
2013-03-17 17:06:42 +01:00
* ------------------------------------------------------------------------
*/
#include "c.h"
#include <signal.h>
initdb needs pqsignal() even on Windows. I had thought we weren't using this version of pqsignal() at all on Windows, but that's wrong --- initdb is using it (and coping with the POSIX-ish semantics of bare signal() :-(). So allow the file to be built in WIN32+FRONTEND case, and add it to the MSVC build logic.
2013-03-17 20:19:47 +01:00
#if !defined(WIN32) || defined(FRONTEND)
Move pqsignal() to libpgport. We had two copies of this function in the backend and libpq, which was already pretty bogus, but it turns out that we need it in some other programs that don't use libpq (such as pg_test_fsync). So put it where it probably should have been all along. The signal-mask-initialization support in src/backend/libpq/pqsignal.c stays where it is, though, since we only need that in the backend.
2013-03-17 17:06:42 +01:00
/*
Run the postmaster's signal handlers without SA_RESTART. The postmaster keeps signals blocked everywhere except while waiting for something to happen in ServerLoop(). The code expects that the select(2) will be cancelled with EINTR if an interrupt occurs; without that, followup actions that should be performed by ServerLoop() itself will be delayed. However, some platforms interpret the SA_RESTART signal flag as meaning that they should restart rather than cancel the select(2). Worse yet, some of them restart it with the original timeout delay, meaning that a steady stream of signal interrupts can prevent ServerLoop() from iterating at all if there are no incoming connection requests. Observable symptoms of this, on an affected platform such as HPUX 10, include extremely slow parallel query startup (possibly as much as 30 seconds) and failure to update timestamps on the postmaster's sockets and lockfiles when no new connections arrive for a long time. We can fix this by running the postmaster's signal handlers without SA_RESTART. That would be quite a scary change if the range of code where signals are accepted weren't so tiny, but as it is, it seems safe enough. (Note that postmaster children do, and must, reset all the handlers before unblocking signals; so this change should not affect any child process.) There is talk of rewriting the postmaster to use a WaitEventSet and not do signal response work in signal handlers, at which point it might be appropriate to revert this patch. But that's not happening before v11 at the earliest. Back-patch to 9.6. The problem exists much further back, but the worst symptom arises only in connection with parallel query, so it does not seem worth taking any portability risks in older branches. Discussion: https://postgr.es/m/9205.1492833041@sss.pgh.pa.us
2017-04-24 19:00:23 +02:00
* Set up a signal handler, with SA_RESTART, for signal "signo"
Move pqsignal() to libpgport. We had two copies of this function in the backend and libpq, which was already pretty bogus, but it turns out that we need it in some other programs that don't use libpq (such as pg_test_fsync). So put it where it probably should have been all along. The signal-mask-initialization support in src/backend/libpq/pqsignal.c stays where it is, though, since we only need that in the backend.
2013-03-17 17:06:42 +01:00
*
initdb needs pqsignal() even on Windows. I had thought we weren't using this version of pqsignal() at all on Windows, but that's wrong --- initdb is using it (and coping with the POSIX-ish semantics of bare signal() :-(). So allow the file to be built in WIN32+FRONTEND case, and add it to the MSVC build logic.
2013-03-17 20:19:47 +01:00
* Returns the previous handler.
Move pqsignal() to libpgport. We had two copies of this function in the backend and libpq, which was already pretty bogus, but it turns out that we need it in some other programs that don't use libpq (such as pg_test_fsync). So put it where it probably should have been all along. The signal-mask-initialization support in src/backend/libpq/pqsignal.c stays where it is, though, since we only need that in the backend.
2013-03-17 17:06:42 +01:00
*/
pqsigfunc
pqsignal(int signo, pqsigfunc func)
{
Remove support for Unix systems without the POSIX signal APIs. Remove configure's checks for HAVE_POSIX_SIGNALS, HAVE_SIGPROCMASK, and HAVE_SIGSETJMP. These APIs are required by the Single Unix Spec v2 (POSIX 1997), which we generally consider to define our minimum required set of Unix APIs. Moreover, no buildfarm member has reported not having them since 2012 or before, which means that even if the code is still live somewhere, it's untested --- and we've made plenty of signal-handling changes of late. So just take these APIs as given and save the cycles for configure probes for them. However, we can't remove as much C code as I'd hoped, because the Windows port evidently still uses the non-POSIX code paths for signal masking. Since we're largely emulating these BSD-style APIs for Windows anyway, it might be a good thing to switch over to POSIX-like notation and thereby remove a few more #ifdefs. But I'm not in a position to code or test that. In the meantime, we can at least make things a bit more transparent by testing for WIN32 explicitly in these places.
2015-08-31 18:55:59 +02:00
#ifndef WIN32
Move pqsignal() to libpgport. We had two copies of this function in the backend and libpq, which was already pretty bogus, but it turns out that we need it in some other programs that don't use libpq (such as pg_test_fsync). So put it where it probably should have been all along. The signal-mask-initialization support in src/backend/libpq/pqsignal.c stays where it is, though, since we only need that in the backend.
2013-03-17 17:06:42 +01:00
struct sigaction act,
oact;
act.sa_handler = func;
sigemptyset(&act.sa_mask);
Use SA_RESTART for all signals, including SIGALRM. The exclusion of SIGALRM dates back to Berkeley days, when Postgres used SIGALRM in only one very short stretch of code. Nowadays, allowing it to interrupt kernel calls doesn't seem like a very good idea, since its use for statement_timeout means SIGALRM could occur anyplace in the code, and there are far too many call sites where we aren't prepared to deal with EINTR failures. When third-party code is taken into consideration, it seems impossible that we ever could be fully EINTR-proof, so better to use SA_RESTART always and deal with the implications of that. One such implication is that we should not assume pg_usleep() will be terminated early by a signal. Therefore, long sleeps should probably be replaced by WaitLatch operations where practical. Back-patch to 9.3 so we can get some beta testing on this change.
2013-06-15 21:39:51 +02:00
act.sa_flags = SA_RESTART;
Move pqsignal() to libpgport. We had two copies of this function in the backend and libpq, which was already pretty bogus, but it turns out that we need it in some other programs that don't use libpq (such as pg_test_fsync). So put it where it probably should have been all along. The signal-mask-initialization support in src/backend/libpq/pqsignal.c stays where it is, though, since we only need that in the backend.
2013-03-17 17:06:42 +01:00
#ifdef SA_NOCLDSTOP
if (signo == SIGCHLD)
act.sa_flags |= SA_NOCLDSTOP;
#endif
if (sigaction(signo, &act, &oact) < 0)
return SIG_ERR;
return oact.sa_handler;
Remove support for Unix systems without the POSIX signal APIs. Remove configure's checks for HAVE_POSIX_SIGNALS, HAVE_SIGPROCMASK, and HAVE_SIGSETJMP. These APIs are required by the Single Unix Spec v2 (POSIX 1997), which we generally consider to define our minimum required set of Unix APIs. Moreover, no buildfarm member has reported not having them since 2012 or before, which means that even if the code is still live somewhere, it's untested --- and we've made plenty of signal-handling changes of late. So just take these APIs as given and save the cycles for configure probes for them. However, we can't remove as much C code as I'd hoped, because the Windows port evidently still uses the non-POSIX code paths for signal masking. Since we're largely emulating these BSD-style APIs for Windows anyway, it might be a good thing to switch over to POSIX-like notation and thereby remove a few more #ifdefs. But I'm not in a position to code or test that. In the meantime, we can at least make things a bit more transparent by testing for WIN32 explicitly in these places.
2015-08-31 18:55:59 +02:00
#else /* WIN32 */
return signal(signo, func);
#endif
Move pqsignal() to libpgport. We had two copies of this function in the backend and libpq, which was already pretty bogus, but it turns out that we need it in some other programs that don't use libpq (such as pg_test_fsync). So put it where it probably should have been all along. The signal-mask-initialization support in src/backend/libpq/pqsignal.c stays where it is, though, since we only need that in the backend.
2013-03-17 17:06:42 +01:00
}
Run the postmaster's signal handlers without SA_RESTART. The postmaster keeps signals blocked everywhere except while waiting for something to happen in ServerLoop(). The code expects that the select(2) will be cancelled with EINTR if an interrupt occurs; without that, followup actions that should be performed by ServerLoop() itself will be delayed. However, some platforms interpret the SA_RESTART signal flag as meaning that they should restart rather than cancel the select(2). Worse yet, some of them restart it with the original timeout delay, meaning that a steady stream of signal interrupts can prevent ServerLoop() from iterating at all if there are no incoming connection requests. Observable symptoms of this, on an affected platform such as HPUX 10, include extremely slow parallel query startup (possibly as much as 30 seconds) and failure to update timestamps on the postmaster's sockets and lockfiles when no new connections arrive for a long time. We can fix this by running the postmaster's signal handlers without SA_RESTART. That would be quite a scary change if the range of code where signals are accepted weren't so tiny, but as it is, it seems safe enough. (Note that postmaster children do, and must, reset all the handlers before unblocking signals; so this change should not affect any child process.) There is talk of rewriting the postmaster to use a WaitEventSet and not do signal response work in signal handlers, at which point it might be appropriate to revert this patch. But that's not happening before v11 at the earliest. Back-patch to 9.6. The problem exists much further back, but the worst symptom arises only in connection with parallel query, so it does not seem worth taking any portability risks in older branches. Discussion: https://postgr.es/m/9205.1492833041@sss.pgh.pa.us
2017-04-24 19:00:23 +02:00
/*
* Set up a signal handler, without SA_RESTART, for signal "signo"
*
* Returns the previous handler.
*
* On Windows, this would be identical to pqsignal(), so don't bother.
*/
#ifndef WIN32
pqsigfunc
pqsignal_no_restart(int signo, pqsigfunc func)
{
struct sigaction act,
oact;
act.sa_handler = func;
sigemptyset(&act.sa_mask);
act.sa_flags = 0;
#ifdef SA_NOCLDSTOP
if (signo == SIGCHLD)
act.sa_flags |= SA_NOCLDSTOP;
#endif
if (sigaction(signo, &act, &oact) < 0)
return SIG_ERR;
return oact.sa_handler;
}
Phase 2 of pgindent updates. Change pg_bsd_indent to follow upstream rules for placement of comments to the right of code, and remove pgindent hack that caused comments following #endif to not obey the general rule. Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using the published version of pg_bsd_indent, but a hacked-up version that tried to minimize the amount of movement of comments to the right of code. The situation of interest is where such a comment has to be moved to the right of its default placement at column 33 because there's code there. BSD indent has always moved right in units of tab stops in such cases --- but in the previous incarnation, indent was working in 8-space tab stops, while now it knows we use 4-space tabs. So the net result is that in about half the cases, such comments are placed one tab stop left of before. This is better all around: it leaves more room on the line for comment text, and it means that in such cases the comment uniformly starts at the next 4-space tab stop after the code, rather than sometimes one and sometimes two tabs after. Also, ensure that comments following #endif are indented the same as comments following other preprocessor commands such as #else. That inconsistency turns out to have been self-inflicted damage from a poorly-thought-through post-indent "fixup" in pgindent. This patch is much less interesting than the first round of indent changes, but also bulkier, so I thought it best to separate the effects. Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
#endif /* !WIN32 */
Run the postmaster's signal handlers without SA_RESTART. The postmaster keeps signals blocked everywhere except while waiting for something to happen in ServerLoop(). The code expects that the select(2) will be cancelled with EINTR if an interrupt occurs; without that, followup actions that should be performed by ServerLoop() itself will be delayed. However, some platforms interpret the SA_RESTART signal flag as meaning that they should restart rather than cancel the select(2). Worse yet, some of them restart it with the original timeout delay, meaning that a steady stream of signal interrupts can prevent ServerLoop() from iterating at all if there are no incoming connection requests. Observable symptoms of this, on an affected platform such as HPUX 10, include extremely slow parallel query startup (possibly as much as 30 seconds) and failure to update timestamps on the postmaster's sockets and lockfiles when no new connections arrive for a long time. We can fix this by running the postmaster's signal handlers without SA_RESTART. That would be quite a scary change if the range of code where signals are accepted weren't so tiny, but as it is, it seems safe enough. (Note that postmaster children do, and must, reset all the handlers before unblocking signals; so this change should not affect any child process.) There is talk of rewriting the postmaster to use a WaitEventSet and not do signal response work in signal handlers, at which point it might be appropriate to revert this patch. But that's not happening before v11 at the earliest. Back-patch to 9.6. The problem exists much further back, but the worst symptom arises only in connection with parallel query, so it does not seem worth taking any portability risks in older branches. Discussion: https://postgr.es/m/9205.1492833041@sss.pgh.pa.us
2017-04-24 19:00:23 +02:00
Phase 2 of pgindent updates. Change pg_bsd_indent to follow upstream rules for placement of comments to the right of code, and remove pgindent hack that caused comments following #endif to not obey the general rule. Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using the published version of pg_bsd_indent, but a hacked-up version that tried to minimize the amount of movement of comments to the right of code. The situation of interest is where such a comment has to be moved to the right of its default placement at column 33 because there's code there. BSD indent has always moved right in units of tab stops in such cases --- but in the previous incarnation, indent was working in 8-space tab stops, while now it knows we use 4-space tabs. So the net result is that in about half the cases, such comments are placed one tab stop left of before. This is better all around: it leaves more room on the line for comment text, and it means that in such cases the comment uniformly starts at the next 4-space tab stop after the code, rather than sometimes one and sometimes two tabs after. Also, ensure that comments following #endif are indented the same as comments following other preprocessor commands such as #else. That inconsistency turns out to have been self-inflicted damage from a poorly-thought-through post-indent "fixup" in pgindent. This patch is much less interesting than the first round of indent changes, but also bulkier, so I thought it best to separate the effects. Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
#endif /* !defined(WIN32) || defined(FRONTEND) */
Reference in New Issue Copy Permalink