Re: OK, so culicidae is *still* broken

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

In response to

Responses

Browse pgsql-hackers by date

  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)