aboutsummaryrefslogtreecommitdiff
path: root/src/backend/access/gist/gistget.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2006-01-19 04:45:47 +0000
committerTom Lane <tgl@sss.pgh.pa.us>2006-01-19 04:45:47 +0000
commit7618330c6d205021a118c1994505be2ceaec25d6 (patch)
treea38905d438fd8d247a33933448b47081b94263fb /src/backend/access/gist/gistget.c
parent49a263011a3770846f612576d8d3408bc3fb8a58 (diff)
downloadpostgresql-7618330c6d205021a118c1994505be2ceaec25d6.tar.gz
postgresql-7618330c6d205021a118c1994505be2ceaec25d6.zip
It turns out that TablespaceCreateDbspace fails badly if a relcache flush
occurs when it tries to heap_open pg_tablespace. When control returns to smgrcreate, that routine will be holding a dangling pointer to a closed SMgrRelation, resulting in mayhem. This is of course a consequence of the violation of proper module layering inherent in having smgr.c call a tablespace command routine, but the simplest fix seems to be to change the locking mechanism. There's no real need for TablespaceCreateDbspace to touch pg_tablespace at all --- it's only opening it as a way of locking against a parallel DROP TABLESPACE command. A much better answer is to create a special-purpose LWLock to interlock these two operations. This drops TablespaceCreateDbspace quite a few layers down the food chain and makes it something reasonably safe for smgr to call.
Diffstat (limited to 'src/backend/access/gist/gistget.c')
0 files changed, 0 insertions, 0 deletions