Horton

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

Noah Misch <noah@leadboat.com>

View thread View on postgr.es
From: Noah Misch <noah@leadboat.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Heath Lord <heath.lord@crunchydata.com>, Andres Freund <andres@anarazel.de>, Thomas Munro <thomas.munro@enterprisedb.com>, Stephen Frost <sfrost@snowman.net>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2018-09-25T15:05:12Z
Lists: pgsql-hackers 
On Mon, Sep 24, 2018 at 01:53:05PM -0400, Tom Lane wrote:
> Noah Misch <noah@leadboat.com> writes:
> > In this proof of concept, the
> > postmaster does not close its copy of a backend socket until the backend
> > exits.
> 
> That seems unworkable because it would interfere with detection of client
> connection drops.  But since you say this is just a POC, maybe you
> intended to fix that?  It'd probably be all right for the postmaster to
> hold onto the socket until the new backend reports successful attach,
> using the same signaling mechanism you had in mind for the other way.

It wasn't relevant to the concept being proven, so I suspended decisions in that
area.  Arranging for socket closure is a simple matter of programming.

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

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.