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

Heath Lord <heath(dot)lord(at)crunchydata(dot)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