Re: Rename max_parallel_degree?

On Mon, Jun 13, 2016 at 5:42 AM, Julien Rouhaud
<julien(dot)rouhaud(at)dalibo(dot)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