]> git.ipfire.org Git - thirdparty/postgresql.git/commit
Be more careful about barriers when releasing BackgroundWorkerSlots.
authorTom Lane <tgl@sss.pgh.pa.us>
Sat, 15 May 2021 16:21:06 +0000 (12:21 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Sat, 15 May 2021 16:21:06 +0000 (12:21 -0400)
commitc76ceacbd0c9bc079fb577e7b707ff3940be9e00
tree11adb9393c3650d5999130ae5ce3912fa5cff474
parente5f982156952c0a9e9380f07a204e808f1fe1fbf
Be more careful about barriers when releasing BackgroundWorkerSlots.

ForgetBackgroundWorker lacked any memory barrier at all, while
BackgroundWorkerStateChange had one but unaccountably did
additional manipulation of the slot after the barrier.  AFAICS,
the rule must be that the barrier is immediately before setting
or clearing slot->in_use.

It looks like back in 9.6 when ForgetBackgroundWorker was first
written, there might have been some case for not needing a
barrier there, but I'm not very convinced of that --- the fact
that the load of bgw_notify_pid is in the caller doesn't seem
to guarantee no memory ordering problem.  So patch 9.6 too.

It's likely that this doesn't fix any observable bug on Intel
hardware, but machines with weaker memory ordering rules could
have problems here.

Discussion: https://postgr.es/m/4046084.1620244003@sss.pgh.pa.us
src/backend/postmaster/bgworker.c