From: Tom Lane <tgl@sss.pgh.pa.us>
To: Noah Misch <noah@leadboat.com>
cc: Heath Lord <heath.lord@crunchydata.com>,
        Stephen Frost <sfrost@snowman.net>,
 Andres Freund <andres@anarazel.de>,
        Thomas Munro <thomas.munro@enterprisedb.com>,
        PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
        joseph.ayers@crunchydata.com
Subject: Re: "could not reattach to shared memory" on buildfarm member dory
In-reply-to: <20190402135442.GA1173872@rfd.leadboat.com>
References: <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>
 <20180925150512.GA3990982@rfd.leadboat.com>
 <20181203053506.GB2860387@rfd.leadboat.com>
 <20190402135442.GA1173872@rfd.leadboat.com>
Comments: In-reply-to Noah Misch <noah@leadboat.com>
	message dated "Tue, 02 Apr 2019 06:54:42 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <18087.1554214140.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Tue, 02 Apr 2019 10:09:00 -0400
Message-ID: <18088.1554214140@sss.pgh.pa.us>
Precedence: bulk

Noah Misch <noah@leadboat.com> writes:
> I can reproduce the 4 MiB allocations described
> in https://postgr.es/m/29823.1525132900@sss.pgh.pa.us; a few times per
> "vcregress check", they emerge in the middle of PGSharedMemoryReAttach()=
.
> The 4 MiB allocations are stacks for new threads of the default thread
> pool[1].

Hah!  It is great to finally have an understanding of what is happening
here.

I worry that your proposed fix is unstable, in particular this assumption
seems shaky:

> + * ... The idea is that, if the allocator handed out
> + * REGION1 pages before REGION2 pages at one occasion, it will do so wh=
enever
> + * both regions are free.

I wonder whether it's possible to address this by configuring the "default
thread pool" to have only one thread?  It seems like the extra threads are
just adding backend startup overhead to no benefit, since we won't use 'em=
.

			regards, tom lane