Re: pgbench: could not connect to server: Resource temporarily unavailable
Thomas Munro <thomas.munro@gmail.com>
From: Thomas Munro <thomas.munro@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andrew Dunstan <andrew@dunslane.net>,
Kevin McKibbin <kevinmckibbin123@gmail.com>, pgsql-performance@lists.postgresql.org
Date: 2022-08-24T04:53:33Z
Lists: 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 :-)
Commits
-
Doc: document possible need to raise kernel's somaxconn limit.
- ba94dfd4c4f6 16.0 landed
- 1a9c3ffd6428 10.23 landed
- 04056e9268be 11.18 landed
- 7951e0d7af98 12.13 landed
- 3ccdeff7bf19 13.9 landed
- 04f1013be084 14.6 landed
- 2c63b0930aee 15.0 landed
-
Doc: prefer sysctl to /proc/sys in docs and comments.
- 4ee6740167b6 16.0 landed
- a0d87e2a92ea 10.23 landed
- d0371f190a1f 11.18 landed
- 384199ec5059 12.13 landed
- 384497f34de5 13.9 landed
- eb0097c6f3ee 14.6 landed
- d53ff6a44b32 15.0 landed
-
Remove our artificial PG_SOMAXCONN limit on listen queue length.
- 0f47457f1129 16.0 landed
-
Instead of believing SOMAXCONN from the system header files (which is
- 153f40067630 7.2.1 cited