| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: OK, so culicidae is *still* broken |
| Date: | 2017-04-15 20:48:05 |
| Message-ID: | 1842.1492289285@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
| Attachment | Content-Type | Size |
|---|---|---|
| allow-control-of-shmem-attach-address.patch | text/x-diff | 1.8 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2017-04-15 21:06:43 | Re: OK, so culicidae is *still* broken |
| Previous Message | Andrew Dunstan | 2017-04-15 20:43:17 | Re: Cutting initdb's runtime (Perl question embedded) |