Re: OK, so culicidae is *still* broken
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org
Date: 2017-04-15T21:06:43Z
Lists: pgsql-hackers
On 2017-04-15 16:48:05 -0400, Tom Lane wrote: > 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. That seems quite reasonable. I'm afraid we're going to have to figure out something similar, but more robust, for windows soon-ish :/ > /* OK, should be able to attach to the segment */ > - memAddress = shmat(shmid, NULL, PG_SHMAT_FLAGS); > + memAddress = shmat(shmid, requestedAddress, PG_SHMAT_FLAGS); > > if (memAddress == (void *) -1) > elog(FATAL, "shmat(id=%d) failed: %m", shmid); As a minor point, it'd probably be good to add addr=%zu, requestedAddress or such. Greetings, Andres Freund
Commits
-
Provide a way to control SysV shmem attach address in EXEC_BACKEND builds.
- 0d7591c67d68 9.2.21 landed
- fddc10146eb2 9.3.17 landed
- 07a990c6e7d1 9.4.12 landed
- bbd4a1b60b6e 9.5.7 landed
- a30f146db4e7 9.6.3 landed
- a74740fbd3bb 10.0 landed
-
Disable RandomizedBaseAddress on MSVC builds
- 7f3e17b4827b 9.4.0 cited