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: Heath Lord <heath.lord@crunchydata.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Noah Misch <noah@leadboat.com>, Thomas Munro <thomas.munro@enterprisedb.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2018-04-30T19:29:53Z
Lists: pgsql-hackers 
Greetings,

* Heath Lord (heath.lord@crunchydata.com) wrote:
>    Any ideas or changes that we could do to help debug or verify would be
> helpful.  We have considered changing it to run everything as SYSTEM but if
> possible we would like to avoid this for security reasons.  Thank you in
> advance and I appreciate all the help.

Just to be clear- there is no longer anything showing up in the event
viewer associated with running the builds.  There may still be an issue
with the system setup or such, but it at least seems less likely for
that to be the issue, so I'm thinking that Tom is more likely correct
that PG is doing something not quite right here.

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.