mirror of
https://github.com/postgres/postgres.git
synced 2026-04-12 04:26:44 -04:00
9abb2bfc04
POSIX sigaction(2) can be told to block a set of signals while a signal handler executes. Make use of that instead of manually blocking and unblocking signals in the postmaster's signal handlers. This should save a few cycles, and it also prevents recursive invocation of signal handlers when many signals arrive in close succession. We have seen buildfarm failures that seem to be due to postmaster stack overflow caused by such recursion (exacerbated by a Linux PPC64 kernel bug). This doesn't change anything about the way that it works on Windows. Somebody might consider adjusting port/win32/signal.c to let it work similarly, but I'm not in a position to do that. For the moment, just apply to HEAD. Possibly we should consider back-patching this, but it'd be good to let it age awhile first. Discussion: https://postgr.es/m/14878.1570820201@sss.pgh.pa.us |
||
|---|---|---|
| .. | ||
| .gitignore | ||
| chklocale.c | ||
| dirent.c | ||
| dirmod.c | ||
| dlopen.c | ||
| erand48.c | ||
| explicit_bzero.c | ||
| fls.c | ||
| fseeko.c | ||
| getaddrinfo.c | ||
| getopt.c | ||
| getopt_long.c | ||
| getpeereid.c | ||
| getrusage.c | ||
| gettimeofday.c | ||
| inet_aton.c | ||
| inet_net_ntop.c | ||
| isinf.c | ||
| kill.c | ||
| Makefile | ||
| mkdtemp.c | ||
| noblock.c | ||
| open.c | ||
| path.c | ||
| pg_bitutils.c | ||
| pg_crc32c_armv8.c | ||
| pg_crc32c_armv8_choose.c | ||
| pg_crc32c_sb8.c | ||
| pg_crc32c_sse42.c | ||
| pg_crc32c_sse42_choose.c | ||
| pg_strong_random.c | ||
| pgcheckdir.c | ||
| pgmkdirp.c | ||
| pgsleep.c | ||
| pgstrcasecmp.c | ||
| pgstrsignal.c | ||
| pqsignal.c | ||
| pread.c | ||
| pthread-win32.h | ||
| pwrite.c | ||
| qsort.c | ||
| qsort_arg.c | ||
| quotes.c | ||
| random.c | ||
| README | ||
| rint.c | ||
| snprintf.c | ||
| sprompt.c | ||
| srandom.c | ||
| strerror.c | ||
| strlcat.c | ||
| strlcpy.c | ||
| strnlen.c | ||
| strtof.c | ||
| system.c | ||
| tar.c | ||
| thread.c | ||
| unsetenv.c | ||
| win32.ico | ||
| win32env.c | ||
| win32error.c | ||
| win32security.c | ||
| win32setlocale.c | ||
| win32ver.rc | ||
src/port/README
libpgport
=========
libpgport must have special behavior. It supplies functions to both
libraries and applications. However, there are two complexities:
1) Libraries need to use object files that are compiled with exactly
the same flags as the library. libpgport might not use the same flags,
so it is necessary to recompile the object files for individual
libraries. This is done by removing -lpgport from the link line:
# Need to recompile any libpgport object files
LIBS := $(filter-out -lpgport, $(LIBS))
and adding infrastructure to recompile the object files:
OBJS= execute.o typename.o descriptor.o data.o error.o prepare.o memory.o \
connect.o misc.o path.o exec.o \
$(filter strlcat.o, $(LIBOBJS))
The problem is that there is no testing of which object files need to be
added, but missing functions usually show up when linking user
applications.
2) For applications, we use -lpgport before -lpq, so the static files
from libpgport are linked first. This avoids having applications
dependent on symbols that are _used_ by libpq, but not intended to be
exported by libpq. libpq's libpgport usage changes over time, so such a
dependency is a problem. Windows, Linux, and macOS use an export list to
control the symbols exported by libpq.