On Mon, Feb 20, 2017 at 7:52 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: > On Sun, Feb 19, 2017 at 8:32 PM, Robert Haas <robertmh...@gmail.com> wrote: >> On Sun, Feb 19, 2017 at 6:50 PM, Amit Kapila <amit.kapil...@gmail.com> wrote: >>> To close the remaining gap, don't you think we can check slot->in_use >>> flag when generation number for handle and slot are same. >> >> That doesn't completely fix it either, because >> ForgetBackgroundWorker() also does >> BackgroundWorkerData->parallel_terminate_count++, which we might also >> fail to see, which would cause RegisterDynamicBackgroundWorker() to >> bail out early. There are CPU ordering effects to think about here, >> not just the order in which the operations are actually performed. >> > > Sure, I think we can attempt to fix that as well by adding write > memory barrier in ForgetBackgroundWorker().
I don't think so. > The main point is if we > keep any loose end in this area, then there is a chance that the > regression test select_parallel can still fail, if not now, then in > future. Another way could be that we can try to minimize the race > condition here and then adjust the select_parallel as suggested above > so that we don't see this failure. My guess is that if we apply the fix I suggested above, it'll be good enough. If that turns out not to be true, then I guess we'll have to deal with that, but why not do the easy thing first? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
