Skip to content
Snippets Groups Projects
Select Git revision
  • benchmark-tools
  • postgres-lambda
  • master default
  • REL9_4_25
  • REL9_5_20
  • REL9_6_16
  • REL_10_11
  • REL_11_6
  • REL_12_1
  • REL_12_0
  • REL_12_RC1
  • REL_12_BETA4
  • REL9_4_24
  • REL9_5_19
  • REL9_6_15
  • REL_10_10
  • REL_11_5
  • REL_12_BETA3
  • REL9_4_23
  • REL9_5_18
  • REL9_6_14
  • REL_10_9
  • REL_11_4
23 results

tablespace.c

  • Tom Lane's avatar
    4513d9de
    It turns out that TablespaceCreateDbspace fails badly if a relcache flush · 4513d9de
    Tom Lane authored
    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.
    4513d9de
    History
    It turns out that TablespaceCreateDbspace fails badly if a relcache flush
    Tom Lane authored
    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.