Skip site navigation (1) Skip section navigation (2)

Re: Tablespace patch review

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>,pgsql-patches(at)postgresql(dot)org
Subject: Re: Tablespace patch review
Date: 2004-06-19 01:47:43
Message-ID: 200406190147.i5J1lhC05652@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > Tom Lane wrote:
> >> Somebody's got to fix oid2name and dbsize though.  Bruce, you want
> >> to catch those?
> 
> > Uh, how do they have to be fixed?  Isn't the relfilenode unchanged?  Do
> > we just need to add tablespace lookups?
> 
> How useful will oid2name be if it doesn't understand about tablespaces?
> I dunno how it ought to be changed, but surely it needs some thought.

Well, I figure we would copy the database capability we have for
tablespaces.

If you call oid2name with no args, you get:
	
	All databases:
	---------------------------------
	17219  = test
	1      = template1
	17218  = template0

If we specify just the database name we get:
	
	(2) aspg oid2name -d template1
	All tables from database "template1":
	---------------------------------
	17147  = sql_features
	17152  = sql_implementation_info
	17157  = sql_languages
	17162  = sql_packages
	17167  = sql_sizing
	17172  = sql_sizing_profiles

I assume we just need to add a tablespace display when run with no args,
and a -s option to display _with_ -d to display only objects in that
database.  We could go fancy and spin through all the databases and list
the datbase name and objects in that tablespace.

> dbsize doesn't even compile right now, because it's using
> GetDatabasePath which now has another argument.  I did not patch it
> because it needs more thought: should it report the total of all
> tablespaces for the database, or should its API be extended so you
> can ask about individual tablespaces, or what?  In any case it's
> not a one-liner fix...

For dbsize, I assume we have to follow the symlinks.  We would have to
spin through all the tablespaces looking for directories with the
database oid.

Given the number of open items for 7.5, I am thinking of keeping this
for post-feature freeze.  Both are contrib.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

In response to

Responses

pgsql-hackers by date

Next:From: Gavin SherryDate: 2004-06-19 01:52:32
Subject: Re: Minor DROP TABLESPACE issue
Previous:From: Tom LaneDate: 2004-06-19 01:36:17
Subject: Re: Minor DROP TABLESPACE issue

pgsql-patches by date

Next:From: Tom LaneDate: 2004-06-19 02:08:28
Subject: Re: Tablespace patch review
Previous:From: Bruce MomjianDate: 2004-06-19 00:05:41
Subject: Re: Tablespace patch review

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group