On Wed, Nov 30, 2016 at 10:22 PM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Wed, Nov 30, 2016 at 8:51 PM, Heikki Linnakangas <hlinn...@iki.fi> wrote: >> On 11/30/2016 09:01 AM, Michael Paquier wrote: >>> +bool >>> +pg_backend_random(char *dst, int len) >>> +{ >>> + int i; >>> + char *end = dst + len; >>> + >>> + /* should not be called in postmaster */ >>> + Assert (IsUnderPostmaster || !IsPostmasterEnvironment); >>> + >>> + LWLockAcquire(BackendRandomLock, LW_EXCLUSIVE); >>> Shouldn't an exclusive lock be taken only when the initialization >>> phase is called? When reading the value a shared lock would be fine. > > Do we need to worry about performance in the case of application doing > small transactions and creating new connections for each transaction? > This would become a contention point when calculating cancel keys for > newly-forked backends. It could be rather easy to measure a > concurrency impact with for example pgbench -C with many concurrent > transactions running something as light as SELECT 1.
I got curious about this point, so I have done a couple of tests with my laptop using the following pgbench command: pgbench -f test.sql -C -c 128 -j 4 -t 100 And test.sql is just that: \set aid random(1,10) In short, a backend is spawned and a cancel key is generated but nothing is done with it to avoid any overhead. With HEAD and the patch without/with --disable-strong-random, I am seeing pretty close numbers. My laptop has only 4 cores, so we may see something on a machine with a higher number of cores. But as far as things go I am in the noise range. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers