From: | "Bossart, Nathan" <bossartn(at)amazon(dot)com> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Worth using personality(ADDR_NO_RANDOMIZE) for EXEC_BACKEND on linux? |
Date: | 2022-01-07 20:20:31 |
Message-ID: | 3818F1F1-D5B3-451B-B0BD-7F9DA2A89813@amazon.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 11/23/21, 11:29 AM, "Thomas Munro" <thomas(dot)munro(at)gmail(dot)com> wrote:
> Here's a patch for Linux and also FreeBSD. The latter OS decided to
> turn on ASLR by default recently, causing my workstation to fail like
> this quite reliably, which reminded me to follow up with this. It
> disables ASLR in pg_ctl and pg_regress, which is enough for check and
> check-world, but doesn't help you if you run the server directly
> (unlike the different hack done for macOS).
>
> For whatever random reason the failures are rarer on Linux (could be
> my imagination, but I think they might be clustered, I didn't look
> into the recipe for the randomness), but even without reproducing a
> failure it's clear to see using pmap that this has the right effect.
> I didn't bother with a check for the existence of ADDR_NO_RANDOMIZE
> because it's since 2.6.12 which is definitely ancient enough.
FWIW I just found this patch very useful for testing some EXEC_BACKEND
stuff on Linux.
Nathan
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2022-01-07 20:22:36 | Re: Disallow quorum uncommitted (with synchronous standbys) txns in logical replication subscribers |
Previous Message | Bossart, Nathan | 2022-01-07 20:20:02 | Re: make MaxBackends available in _PG_init |