From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
cc: pgsql-hackers@postgresql.org
Subject: Re: OK, so culicidae is *still* broken
In-reply-to: <32559.1492278226@sss.pgh.pa.us>
References: <7036.1492231361@sss.pgh.pa.us>
 <18D5D7AF-C587-4B63-B2CF-13590849A624@anarazel.de>
 <32559.1492278226@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Sat, 15 Apr 2017 13:43:46 -0400"
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0"
Content-ID: <1785.1492289181.0@sss.pgh.pa.us>
Date: Sat, 15 Apr 2017 16:48:05 -0400
Message-ID: <1842.1492289285@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1785.1492289181.1@sss.pgh.pa.us>

I wrote:
> I think what may be the most effective way to proceed is to provide
> a way to force the shmem segment to be mapped at a chosen address.
> It looks like, at least on x86_64 Linux, mapping shmem at
> 0x00007E0000000000 would work reliably.

> Since we only care about this for testing purposes, I don't think
> it has to be done in any very clean or even documented way.
> I'm inclined to propose that we put something into sysv_shmem.c
> that will check for an environment variable named, say, PG_SHMEM_ADDR,
> and if it's set will use the value as the address in the initial
> shmat() call.  For a bit of extra safety we could do that only in
> EXEC_BACKEND builds.

Concretely, I propose the attached patch.  We'd have to put it into
all supported branches, since culicidae is showing intermittent
"could not reattach to shared memory" failures in all the branches.

			regards, tom lane


------- =_aaaaaaaaaa0
Content-Type: text/x-diff; name="allow-control-of-shmem-attach-address.patch";
	charset="us-ascii"
Content-ID: <1785.1492289181.2@sss.pgh.pa.us>
Content-Description: allow-control-of-shmem-attach-address.patch
Content-Transfer-Encoding: quoted-printable

diff --git a/src/backend/port/sysv_shmem.c b/src/backend/port/sysv_shmem.c
index 77cd8f3..15ae672 100644
*** a/src/backend/port/sysv_shmem.c
--- b/src/backend/port/sysv_shmem.c
*************** static void *
*** 102,109 ****
--- 102,129 ----
  InternalIpcMemoryCreate(IpcMemoryKey memKey, Size size)
  {
  	IpcMemoryId shmid;
+ 	void	   *requestedAddress =3D NULL;
  	void	   *memAddress;
=20=20
+ 	/*
+ 	 * Normally we just pass requestedAddress =3D NULL to shmat(), allowing =
the
+ 	 * system to choose where the segment gets mapped.  But in an EXEC_BACKE=
ND
+ 	 * build, it's possible for whatever is chosen in the postmaster to not
+ 	 * work for backends, due to variations in address space layout.  As a
+ 	 * rather klugy workaround, allow the user to specify the address to use
+ 	 * via setting the environment variable PG_SHMEM_ADDR.  (If this were of
+ 	 * interest for anything except debugging, we'd probably create a cleaner
+ 	 * and better-documented way to set it, such as a GUC.)
+ 	 */
+ #ifdef EXEC_BACKEND
+ 	{
+ 		char	   *pg_shmem_addr =3D getenv("PG_SHMEM_ADDR");
+=20
+ 		if (pg_shmem_addr)
+ 			requestedAddress =3D (void *) strtoul(pg_shmem_addr, NULL, 0);
+ 	}
+ #endif
+=20
  	shmid =3D shmget(memKey, size, IPC_CREAT | IPC_EXCL | IPCProtection);
=20=20
  	if (shmid < 0)
*************** InternalIpcMemoryCreate(IpcMemoryKey mem
*** 203,209 ****
  	on_shmem_exit(IpcMemoryDelete, Int32GetDatum(shmid));
=20=20
  	/* OK, should be able to attach to the segment */
! 	memAddress =3D shmat(shmid, NULL, PG_SHMAT_FLAGS);
=20=20
  	if (memAddress =3D=3D (void *) -1)
  		elog(FATAL, "shmat(id=3D%d) failed: %m", shmid);
--- 223,229 ----
  	on_shmem_exit(IpcMemoryDelete, Int32GetDatum(shmid));
=20=20
  	/* OK, should be able to attach to the segment */
! 	memAddress =3D shmat(shmid, requestedAddress, PG_SHMAT_FLAGS);
=20=20
  	if (memAddress =3D=3D (void *) -1)
  		elog(FATAL, "shmat(id=3D%d) failed: %m", shmid);

------- =_aaaaaaaaaa0
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

------- =_aaaaaaaaaa0--