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: Stephen Frost <sfrost@snowman.net>, Noah Misch <noah@leadboat.com>, Thomas Munro <thomas.munro@enterprisedb.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2018-04-30T19:45:06Z
Lists: pgsql-hackers 
Heath Lord <heath.lord@crunchydata.com> writes:
>    So what I noticed after adding the '--force' flag was that in the Event
> Viewer logs there was an Error in the System log stating that "The
> application-specific permission settings do not grant Local Activation
> permission for the COM Server application" for the Runtime Broker.  So
> around 2:00 pm today I went and changed the ownership of the registry
> values to Administrators so I could add the user we are running the builds
> under to the list of members that have access to it.  However right after I
> made that change the build was actually broken for me so I am just now
> turning the builds back on to run constantly to verify if this has
> any effect on the issue of not being able to reattach to the shared
> memory.  I am hoping that this makes things more stable, however I am not
> confident that these are related.

The build was broken on Windows between about 12:30 and 14:30 EDT,
thanks to an unrelated change.  Now that that's sorted, dory is
still failing :-(.

Moreover, even though I took out the module dump logic, the failure rate
is still a good bit higher than it was before, which seems to confirm my
fear that this is a Heisenbug: either VirtualQuery itself, or the act of
elog'ing a bunch of output, is causing memory allocations to take place
that otherwise would not have.

I'm hoping that the elog output is to blame for that, and am going to
go try to rejigger the code so that we capture the memory maps into space
that was allocated before VirtualFree.

>    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.

Yeah, that's no solution.  Even if it were OK for dory, end users wouldn't
necessarily want to run PG that way.

			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.