diff options
author | Tom Lane <tgl@sss.pgh.pa.us> | 2006-01-19 04:45:58 +0000 |
---|---|---|
committer | Tom Lane <tgl@sss.pgh.pa.us> | 2006-01-19 04:45:58 +0000 |
commit | 9fad6e338be9428a7c6bd14b1f08057f20161253 (patch) | |
tree | 8f6908f2cbe97b4773384ed5154c46cede2ee581 /src/tutorial/syscat.source | |
parent | 754da88e19e56a6aaba06a57f45fdf1b5ae792a3 (diff) | |
download | postgresql-9fad6e338be9428a7c6bd14b1f08057f20161253.tar.gz postgresql-9fad6e338be9428a7c6bd14b1f08057f20161253.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/tutorial/syscat.source')
0 files changed, 0 insertions, 0 deletions