Re: pgbench: could not connect to server: Resource temporarily unavailable
От | Thomas Munro |
---|---|
Тема | Re: pgbench: could not connect to server: Resource temporarily unavailable |
Дата | |
Msg-id | CA+hUKG+=jNKh8m0181PxASELK5porOPDxRdaAMK5_Ub2b0SwMg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pgbench: could not connect to server: Resource temporarily unavailable (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-performance |
On Wed, Aug 24, 2022 at 3:06 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Thomas Munro <thomas.munro@gmail.com> writes: > > Oh, one comment there is actually obsolete now AFAIK. Unless there is > > some reason to think personality(ADDR_NO_RANDOMIZE) might not work in > > some case where sysctl -w kernel.randomize_va_space=0 will, I think we > > can just remove that. > > AFAICS, f3e78069db7 silently does nothing on platforms lacking > ADDR_NO_RANDOMIZE and PROC_ASLR_FORCE_DISABLE. Are you asserting > there are no such platforms? That's a Linux-only sysctl. ADDR_NO_RANDOMIZE is also Linux-only. Both controls are old enough to be in any kernel that anyone's developing on. On further reflection, though, I guess the comment is still useful. ADDR_NO_RANDOMIZE only helps you with clusters launched by pg_ctl and pg_regress. A developer trying to run "postgres" directly might still want to know about the sysctl, so I withdraw that idea. As for whether there are platforms where it does nothing: definitely. These are highly OS-specific, and we've only tackled Linux and FreeBSD (with other solutions for macOS and Windows elsewhere in the tree), but I doubt it matters: these are just the OSes that have ASLR on by default, that someone in our community uses as a daily driver to hack PostgreSQL on, that has been annoyed enough to look up how to turn it off :-)
В списке pgsql-performance по дате отправления: