On 26/06/2016 08:37, Amit Kapila wrote: > On Sat, Jun 25, 2016 at 2:27 PM, Julien Rouhaud > <julien.rouh...@dalibo.com> wrote: >>> >> >> It's better thanks. Should we document somewhere the link between this >> parameter and custom dynamic background workers or is it pretty >> self-explanatory? >> > > How about if add an additiona line like: > Parallel workers are taken from the pool of processes established by > guc-max-worker-processes. > > I think one might feel some duplication of text between this and what > we have for max_parallel_workers_per_gather, but it seems genuine to > me. >
Ok, I'll add it. > > @@ -370,6 +379,8 @@ ForgetBackgroundWorker(slist_mutable_iter *cur) > Assert(rw->rw_shmem_slot < > max_worker_processes); > slot = &BackgroundWorkerData->slot[rw->rw_shmem_slot]; > slot->in_use = > false; > + if (slot->parallel) > + BackgroundWorkerData->parallel_terminate_count++; > > I think operations on parallel_terminate_count are not safe. > ForgetBackgroundWorker() and RegisterDynamicBackgroundWorker() can try > to read write at same time. It seems you need to use atomic > operations to ensure safety. > > But operations on parallel_terminate_count are done by the postmaster, and per Robert's previous email postmaster can't use atomics: > 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. Do we support platforms on which 32bits operations are not atomic? -- Julien Rouhaud http://dalibo.com - http://dalibo.org -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
