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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
