Horton

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

Stephen Frost <sfrost@snowman.net>

View thread View on postgr.es
From: Stephen Frost <sfrost@snowman.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Noah Misch <noah@leadboat.com>, Thomas Munro <thomas.munro@enterprisedb.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Heath Lord <heath.lord@crunchydata.com>
Date: 2018-04-30T18:34:28Z
Lists: pgsql-hackers 
Greetings,

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> [ Thanks to Stephen for cranking up a continuous build loop on dory ]

That was actually Heath, who is also trying to work this issue and has
an idea about something else which might help (and some more information
about what's happening in the event log).  Adding him to the thread so
he can (easily) reply with what he's found.

Heath..?

Thanks!

Stephen

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.