Horton

Re: "could not reattach to shared memory" on buildfarm member dory

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Heath Lord <heath.lord@crunchydata.com>
Cc: Andres Freund <andres@anarazel.de>, Noah Misch <noah@leadboat.com>, Thomas Munro <thomas.munro@enterprisedb.com>, Stephen Frost <sfrost@snowman.net>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2018-05-01T15:31:50Z
Lists: pgsql-hackers 
Well, at this point the only thing that's entirely clear is that none
of the ideas I had work.  I think we are going to be forced to pursue
Noah's idea of doing an end-to-end retry.  Somebody else will need to
take point on that; I lack a Windows environment and have already done
a lot more blind patch-pushing than I like in this effort.

I'll revert the debugging code I added to win32_shmem.c, unless
someone sees a reason to leave it there awhile longer.

			regards, tom lane

Commits

  1. Avoid "could not reattach" by providing space for concurrent allocation.

  2. Assert that pgwin32_signal_initialize() has been called early enough.

  3. Remove investigative code for can't-reattach-to-shared-memory errors.

  4. Does it help to wait before reattaching?

  5. Map and unmap the shared memory block before risking VirtualFree.

  6. Further effort at preventing memory map dump from affecting the results.

  7. Remove Windows module-list-dumping code.

  8. Dump full memory maps around failing Windows reattach code.

  9. Get still more info about Windows can't-reattach-to-shared-memory errors.

  10. Get more info about Windows can't-reattach-to-shared-memory errors.

  11. Try to get some info about Windows can't-reattach-to-shared-memory errors.