From: | tgl(at)postgresql(dot)org (Tom Lane) |
---|---|
To: | pgsql-committers(at)postgresql(dot)org |
Subject: | pgsql: It turns out that TablespaceCreateDbspace fails badly if a |
Date: | 2006-01-19 04:45:38 |
Message-ID: | 20060119044538.B244B9DC85D@postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
Log Message:
-----------
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.
Modified Files:
--------------
pgsql/src/backend/commands:
tablespace.c (r1.28 -> r1.29)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/tablespace.c.diff?r1=1.28&r2=1.29)
pgsql/src/include/storage:
lwlock.h (r1.25 -> r1.26)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/storage/lwlock.h.diff?r1=1.25&r2=1.26)
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-01-19 04:45:47 | pgsql: It turns out that TablespaceCreateDbspace fails badly if a |
Previous Message | Tom Lane | 2006-01-19 00:27:28 | pgsql: Fix a tiny memory leak (one List header) in |