mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-08-28 17:17:18 +02:00
6322e84430
whether to execute an immediate interrupt, rather than testing whether LockWaitCancel() cancelled a lock wait. The old way misclassified the case where we were blocked in ProcWaitForSignal(), and arguably would misclassify any other future additions of new ImmediateInterruptOK states too. This allows reverting the old kluge that gave LockWaitCancel() a return value, since no callers care anymore. Improve comments in the various implementations of PGSemaphoreLock() to explain that on some platforms, the assumption that semop() exits after a signal is wrong, and so we must ensure that the signal handler itself throws elog if we want cancel or die interrupts to be effective. Per testing related to bug #3883, though this patch doesn't solve those problems fully. Perhaps this change should be back-patched, but since pre-8.3 branches aren't really relying on autovacuum to respond to SIGINT, it doesn't seem critical for them. |
||
|---|---|---|
| .. | ||
| aix | ||
| darwin | ||
| dynloader | ||
| hpux | ||
| nextstep | ||
| sunos4 | ||
| tas | ||
| win32 | ||
| ipc_test.c | ||
| Makefile | ||
| posix_sema.c | ||
| sysv_sema.c | ||
| sysv_shmem.c | ||
| win32_sema.c | ||
| win32_shmem.c | ||