]> granicus.if.org Git - postgresql/commit
Fix race in dsm_attach() when handles are reused.
authorThomas Munro <tmunro@postgresql.org>
Thu, 14 Feb 2019 21:19:11 +0000 (10:19 +1300)
committerThomas Munro <tmunro@postgresql.org>
Fri, 15 Feb 2019 01:05:09 +0000 (14:05 +1300)
commit6c0fb941892519ad6b8873e99c4001404fb9a128
tree3f5dbc118ac58a938d21b19034ebdb59ce9698ed
parent8fd3fdd85a3e22f04b2cb0949450f63cb48952cd
Fix race in dsm_attach() when handles are reused.

DSM handle values can be reused as soon as the underlying shared memory
object has been destroyed.  That means that for a brief moment we
might have two DSM slots with the same handle.  While trying to attach,
if we encounter a slot with refcnt == 1, meaning that it is currently
being destroyed, we should continue our search in case the same handle
exists in another slot.

The race manifested as a rare "dsa_area could not attach to segment"
error, and was more likely in 10 and 11 due to the lack of distinct
seed for random() in parallel workers.  It was made very unlikely in
in master by commit 197e4af9, and older releases don't usually create
new DSM segments in background workers so it was also unlikely there.

This fixes the root cause of bug report #15585, in which the error
could also sometimes result in a self-deadlock in the error path.
It's not yet clear if further changes are needed to avoid that failure
mode.

Back-patch to 9.4, where dsm.c arrived.

Author: Thomas Munro
Reported-by: Justin Pryzby, Sergei Kornilov
Discussion: https://postgr.es/m/20190207014719.GJ29720@telsasoft.com
Discussion: https://postgr.es/m/15585-324ff6a93a18da46@postgresql.org
src/backend/storage/ipc/dsm.c