pgsql: Avoid "could not reattach" by providing space for concurrent all
Avoid "could not reattach" by providing space for concurrent allocation.
We've long had reports of intermittent "could not reattach to shared
memory" errors on Windows. Buildfarm member dory fails that way when
PGSharedMemoryReAttach() execution overlaps with creation of a thread
for the process's "default thread pool". Fix that by providing a second
region to receive asynchronous allocations that would otherwise intrude
into UsedShmemSegAddr. In pgwin32_ReserveSharedMemoryRegion(), stop
trying to free reservations landing at incorrect addresses; the caller's
next step has been to terminate the affected process. Back-patch to 9.4
(all supported versions).
Reviewed by Tom Lane. He also did much of the prerequisite research;
see commit bcbf2346d69f6006f126044864dd9383d50d87b4.
Discussion: /messages/by-id/20190402135442.GA1173872@rfd.leadboat.com
Branch
------
REL_10_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/f5989b379cefa0f3c858401d671813630e5e4118
Modified Files
--------------
src/backend/port/win32_shmem.c | 92 +++++++++++++++++++++++++++++++------
src/backend/postmaster/postmaster.c | 7 +++
src/include/storage/pg_shmem.h | 1 +
3 files changed, 86 insertions(+), 14 deletions(-)
On Tue, Apr 9, 2019 at 12:44 AM Noah Misch <noah@leadboat.com> wrote:
Avoid "could not reattach" by providing space for concurrent allocation.
This has broken builds on frogmouth, and I'm betting any mingw animal.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Tue, Apr 09, 2019 at 10:22:55AM -0400, Andrew Dunstan wrote:
On Tue, Apr 9, 2019 at 12:44 AM Noah Misch <noah@leadboat.com> wrote:
Avoid "could not reattach" by providing space for concurrent allocation.
This has broken builds on frogmouth, and I'm betting any mingw animal.
Fixed in ba3fb5d.