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: <20190407043221.GA1914190@rfd.leadboat.com>
References: <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> <18088.1554214140@sss.pgh.pa.us>
 <20190407043221.GA1914190@rfd.leadboat.com>
Comments: In-reply-to Noah Misch <noah@leadboat.com>
	message dated "Sat, 06 Apr 2019 21:32:21 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <32722.1554612203.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Sun, 07 Apr 2019 00:43:23 -0400
Message-ID: <32723.1554612203@sss.pgh.pa.us>
Precedence: bulk

Noah Misch <noah@leadboat.com> writes:
> On Tue, Apr 02, 2019 at 10:09:00AM -0400, Tom Lane wrote:
>> I worry that your proposed fix is unstable, in particular this assumpti=
on
>> seems shaky:
>>> + * ... The idea is that, if the allocator handed out
>>> + * REGION1 pages before REGION2 pages at one occasion, it will do so =
whenever
>>> + * both regions are free.

> True.  If Windows changes to prefer allocating from the most recently fr=
eed
> region, shmem-protective-region-v1.patch would cease to help.  It's not
> impossible.

>> I wonder whether it's possible to address this by configuring the "defa=
ult
>> 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.

> I didn't find a way to configure the pool's size.

Seems odd ...

> Another option is to reattach shared memory earlier, before the default =
thread
> pool starts.  A Windows application using only the unavoidable DLLs
> (kernel32.dll, ntdll.dll, kernelbase.dll) doesn't get a default thread p=
ool;
> the pool starts when one loads ws2_32.dll, ucrtbased.dll, etc.  Hence, t=
he
> DllMain() function of a DLL that loads early could avoid the problem.  (=
Cygwin
> fork() uses that route to remap shared memory, though it also retries fa=
iled
> forks.)  If we proceed that way, we'd add a tiny pg_shmem.dll that appea=
rs
> early in the load order, just after the unavoidable DLLs.  It would extr=
act
> applicable parameters from the command line and reattach shared memory. =
 When
> it fails, it would set a flag so the usual code can raise an error.  Doe=
s that
> sound more or less attractive than shmem-protective-region-v1.patch?

Well, it definitely sounds like more work.  Let's not do such work
until we have to.  Your patch has the advantages of being (a) small
and (b) done, and there's much to be said for that.

			regards, tom lane