
> > Ahh. I forgot to detail my ideas on this. It seems to me that we cannot
> > drop a table space until the directory is empty.

Agreed.

> 
> How would it get to be empty?  Are you thinking of some sort of "connect
> database to tablespace" and "disconnect database from tablespace"
> commands that would respectively create and delete the per-database
> subdirectory?  That seems moderately reasonable to me.  We could then

I would only allow the drop if the directory only contains empty db oid 
directories.

Andreas

Fri, 27 Feb 2004 10:00:29 +0100
"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>
Re: Tablespaces
On Fri, 27 Feb 2004, Zeugswetter Andreas SB SD wrote:

> 
> > > Ahh. I forgot to detail my ideas on this. It seems to me that we cannot
> > > drop a table space until the directory is empty.
> 
> Agreed.
> 
> > 
> > How would it get to be empty?  Are you thinking of some sort of "connect
> > database to tablespace" and "disconnect database from tablespace"
> > commands that would respectively create and delete the per-database
> > subdirectory?  That seems moderately reasonable to me.  We could then
> 
> I would only allow the drop if the directory only contains empty db oid 
> directories.

Wouldn't this be better tracked in the dependency tracking that's already 
built into postgresql?  Checking to see if the directory is empty is open 
to race conditions, but locking the dependency tracking while dropping a 
tablespace isn't.



Fri, 27 Feb 2004 08:27:02 -0700 (MST)
"scott.marlowe" <scott.marlowe@ihs.com>
Re: Tablespaces
"scott.marlowe" <scott.marlowe@ihs.com> writes:
> On Fri, 27 Feb 2004, Zeugswetter Andreas SB SD wrote:
>>> How would it get to be empty?  Are you thinking of some sort of "connect
>>> database to tablespace" and "disconnect database from tablespace"
>>> commands that would respectively create and delete the per-database
>>> subdirectory?  That seems moderately reasonable to me.  We could then
>> 
>> I would only allow the drop if the directory only contains empty db oid 
>> directories.

That's subject to race conditions (ie, someone creating a table about
the same time you are deciding it's okay to drop the tablespace).  There
needs to be some interlock, and I think that associating that lock with
infrequently executed connect/disconnect operations would be good from a
performance standpoint.

> Wouldn't this be better tracked in the dependency tracking that's already 
> built into postgresql?

No, because dependencies are local to individual databases.

			regards, tom lane

Fri, 27 Feb 2004 11:42:46 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Tablespaces 