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

On Sun, Dec 02, 2018 at 09:35:06PM -0800, Noah Misch wrote:
> On Tue, Sep 25, 2018 at 08:05:12AM -0700, Noah Misch wrote:
> > On Mon, Sep 24, 2018 at 01:53:05PM -0400, Tom Lane wrote:
> > > Overall, I agree that neither of these approaches are exactly attractive.
> > > We're paying a heck of a lot of performance or complexity to solve a
> > > problem that shouldn't even be there, and that we don't understand well.
> > > In particular, the theory that some privileged code is injecting a thread
> > > into every new process doesn't square with my results at
> > > https://www.postgresql.org/message-id/15345.1525145612%40sss.pgh.pa.us
> > >
> > > I think our best course of action at this point is to do nothing until
> > > we have a clearer understanding of what's actually happening on dory.
> > > Perhaps such understanding will yield an idea for a less painful fix.
> >
> > I see.
>
> Could one of you having a dory login use
> https://live.sysinternals.com/Procmon.exe to capture process events during
> backend startup?

Ping.

> The ideal would be one capture where startup failed reattach
> and another where it succeeded, but having the successful run alone would be a
> good start. The procedure is roughly this:
>
> - Install PostgreSQL w/ debug symbols.
> - Start a postmaster.
> - procmon /nomonitor
> - procmon "Filter" menu -> Enable Advanced Output
> - Ctrl-l, add filter for "Process Name" is "postgres.exe"
> - Ctrl-e (starts collecting data)
> - psql (leave it running)
> - After ~60s, Ctrl-e again in procmon (stops collecting data)
> - File -> Save -> PML
> - File -> Save -> XML, include stack traces, resolve stack symbols
> - Compress the PML and XML files, and mail them here