Date: Tue, 25 Sep 2018 08:05:12 -0700
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>
Subject: Re: "could not reattach to shared memory" on buildfarm member dory
Message-ID: <20180925150512.GA3990982@rfd.leadboat.com>
References: <20180423231855.GK27724@tamriel.snowman.net>
 <CAEepm=0kRF7Hrd2R72FJLdQneV1HATjJM_ArbjZw=-ZF3RT7+Q@mail.gmail.com>
 <20180424070646.GA2693533@rfd.leadboat.com>
 <17897.1525108069@sss.pgh.pa.us>
 <29823.1525132900@sss.pgh.pa.us>
 <20180501002419.onmikldoe2ssjauq@alap3.anarazel.de>
 <18056.1525148010@sss.pgh.pa.us>
 <22096.1525188710@sss.pgh.pa.us>
 <20180819020007.GD3795674@rfd.leadboat.com>
 <14554.1537811585@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <14554.1537811585@sss.pgh.pa.us>
User-Agent: Mutt/1.5.24 (2015-08-30)
Precedence: bulk

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.