On Mon, Jun 13, 2016 at 5:42 AM, Julien Rouhaud <julien.rouh...@dalibo.com> wrote: > Agreed, and fixed in attached v3.
I don't entirely like the new logic in RegisterDynamicBackgroundWorker. I wonder if we can't drive this off of a couple of counters, instead of having the process registering the background worker iterate over every slot. Suppose we add two counters to BackgroundWorkerArray, parallel_register_count and parallel_terminate_count. Whenever a backend successfully registers a parallel worker, it increments parallel_register_count. Whenever the postmaster marks a parallel wokrer slot as no longer in use, it increments parallel_terminate_count. Then, the number of active parallel workers is just parallel_register_count - parallel_terminate_count. (We can't have the postmaster and the backends share the same counter, because then it would need locking, and the postmaster can't try to take spinlocks - can't even use atomics, because those might be emulated using spinlocks.) Of course, it would be nice if we could make these counters 64-bit integers, but we can't, because we don't rely on 64-bit reads and writes to be atomic on all platforms. So instead they'll have to be uint32. That means they could wrap (if you really work at it) but subtraction will still return the right answer, so it's OK. If we want to allow the number of parallel workers started to be available for statistical purposes, we can keep to uint32 values for that (parallel_register_count_lo and parallel_register_count_hi, for example), and increment the second one whenever the first one rolls over to zero. Thoughts? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers