-Original Message-
From: [EMAIL PROTECTED] on behalf of Bruce Momjian
Sent: Sat 6/19/2004 1:05 AM
To: Andreas Pflug
Cc: Tom Lane; Gavin Sherry; PostgreSQL-patches
Subject: Re: [PATCHES] Tablespace patch review
We can build a gui on top of the command-line tool, no?
No, we
Tom Lane wrote:
Andreas Pflug [EMAIL PROTECTED] writes:
Tom Lane wrote:
As for the authentication-is-expensive issue, what of it? You *should*
have to authenticate yourself in order to look inside another person's
database. The sort of cross-database inspection being proposed here
would
Dave Page wrote:
-Original Message-
From: [EMAIL PROTECTED] on behalf of Bruce Momjian
Sent: Sat 6/19/2004 1:05 AM
To: Andreas Pflug
Cc: Tom Lane; Gavin Sherry; PostgreSQL-patches
Subject: Re: [PATCHES] Tablespace patch review
We can build a gui on top of the command-line tool
Bruce Momjian wrote:
I don't see why an admin tool can't connect to each database and get a
listing of what is in each tablespace. I don't think connecting to 100
databases to get that information will be slow.
Well, whatever you call slow or not slow.
I checked it; connecting 10 databases,
-Original Message-
From: Andreas Pflug [mailto:[EMAIL PROTECTED]
Sent: Sat 6/19/2004 6:40 PM
To: Bruce Momjian
Cc: Dave Page; Tom Lane; PostgreSQL-patches
Subject: Re: [PATCHES] Tablespace patch review
Well, whatever you call slow or not slow.
I checked it; connecting 10
Dave Page wrote:
-Original Message-
From: Andreas Pflug [mailto:[EMAIL PROTECTED]
Sent: Sat 6/19/2004 6:40 PM
To: Bruce Momjian
Cc: Dave Page; Tom Lane; PostgreSQL-patches
Subject: Re: [PATCHES] Tablespace patch review
Well, whatever you call slow or not slow.
I checked it; connecting
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Well, I didn't use tablespaces here so the pg_tablespaces directory is
empty, so I can't think of what the tablespace is.
You look in the pg_tablespace catalog for the row with that OID.
Also, are we calling it pg_tablespaces
Andreas Pflug wrote:
Bruce Momjian wrote:
I don't see why an admin tool can't connect to each database and get a
listing of what is in each tablespace. I don't think connecting to 100
databases to get that information will be slow.
Well, whatever you call slow or not slow.
I
Bruce Momjian [EMAIL PROTECTED] writes:
OK, I have reviewed the patch. I think Tom is doing the same, but I
want to report the things I found.
I just came up for air after about two solid days of working on this
patch ... had not seen your message before committing it. The good
news is that I
Bruce Momjian [EMAIL PROTECTED] writes:
I have a few other questions:
What is the procedure for moving tablespace directories?
There is none.
However, pg_tablespace still has the old location.
Yup. The *only* thing that pg_tablespace.spclocation is used for is
for pg_dumpall to dump
On Fri, 18 Jun 2004, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
OK, I have reviewed the patch. I think Tom is doing the same, but I
want to report the things I found.
I just came up for air after about two solid days of working on this
patch ... had not seen your message
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I have a few other questions:
What is the procedure for moving tablespace directories?
There is none.
However, pg_tablespace still has the old location.
Yup. The *only* thing that pg_tablespace.spclocation is used for is
Tom Lane wrote:
Are we ripping out our initlocation code at the same time?
Not done yet, but it's dead and should be removed as soon as a
decent respect for the deceased permits ;-)
You want me to do the honors?
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Are we ripping out our initlocation code at the same time?
Not done yet, but it's dead and should be removed as soon as a
decent respect for the deceased permits ;-)
You want me to do the honors?
Nah, I'll get it. I want to do some
Bruce Momjian [EMAIL PROTECTED] 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
On Fri, 18 Jun 2004, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Are we ripping out our initlocation code at the same time?
Not done yet, but it's dead and should be removed as soon as a
decent respect for the deceased permits ;-)
You want me to do the
On Fri, 18 Jun 2004, Bruce Momjian wrote:
[snip]
TODO. You sound like a man who's expecting a
several-generations-polished facility when we only just committed
the first version today. I do not feel a need to have any of these
features in 7.5 ...
I just need to know what to add to
Gavin Sherry wrote:
On Fri, 18 Jun 2004, Andreas Pflug wrote:
Gavin Sherry wrote:
On Fri, 18 Jun 2004, Bruce Momjian wrote:
[snip]
TODO. You sound like a man who's expecting a
several-generations-polished facility when we only just committed
the first version today. I do not feel
On Sat, 19 Jun 2004, Andreas Pflug wrote:
[snip]
I don't think we should try and show all objects for a tablespace in
information_schema.
Agreed, information_schema is database specific. I was thinking about a
pg_tablespace_contents(..) function anyway.
Being able to list all objects in
Gavin Sherry wrote:
I would debate that.
Firstly, tablespaces aren't supported on windows yet.
Just a matter of time. And I'm talking of win32 workstations connecting
to *ix servers too.
Secondly, I'd think
that Unix users would be fine with a command line tool, especially one
that can connect
Andreas Pflug [EMAIL PROTECTED] writes:
IMHO checking objects in a tablespace is a routine administrative task,
so it should be supported natively by the server without need of
contribs.
I strongly disagree. Dropping a tablespace is not a routine activity,
and we don't have to have
Tom Lane wrote:
Andreas Pflug [EMAIL PROTECTED] writes:
IMHO checking objects in a tablespace is a routine administrative task,
so it should be supported natively by the server without need of
contribs.
I strongly disagree. Dropping a tablespace is not a routine activity,
Dropping
Andreas Pflug [EMAIL PROTECTED] writes:
Tom Lane wrote:
As for the authentication-is-expensive issue, what of it? You *should*
have to authenticate yourself in order to look inside another person's
database. The sort of cross-database inspection being proposed here
would be a big security
Andreas Pflug wrote:
And for win user acceptance, a command line tool won't be
sufficient either.
This does not deserve a response.
Well, that's not quite appropriate. A 'command line is enough for server
maintenance' attitude won't attract win people; they're blind
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
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.
I assume we just need to add a tablespace display when run with no args,
and a -s option to
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
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.
I assume we just need to add a tablespace display when run with no args,
Are we ripping out our initlocation code at the same time?
Not done yet, but it's dead and should be removed as soon as a
decent respect for the deceased permits ;-)
You want me to do the honors?
What about people upgrading from 7.4 databases that used database locations?
Chris
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
What about people upgrading from 7.4 databases that used database locations?
They'll get a nice warning:
regression=# create database foo location 'bar';
WARNING: LOCATION is not supported anymore
HINT: Consider using tablespaces instead.
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
I should think that the table-level display ought to show both the
relfilenode and tablespace OIDs for each table.
For objects in the default tablespace, they don't show a tablespace oid,
right? Where do we put it? A column that will
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
I should think that the table-level display ought to show both the
relfilenode and tablespace OIDs for each table.
For objects in the default tablespace, they don't show a tablespace oid,
right? Where do we put
Bruce Momjian [EMAIL PROTECTED] writes:
Well, I didn't use tablespaces here so the pg_tablespaces directory is
empty, so I can't think of what the tablespace is.
You look in the pg_tablespace catalog for the row with that OID.
Also, are we calling it pg_tablespaces (plural) rather than
Gavin Sherry wrote:
Attached is an updated patch, fixing a compile error which my compiler
didn't seem to detect/suffer from and incorporating fixes to problems
raised by Neil.
Thanks,
Gavin
OK, I have reviewed the patch. I think Tom is doing the same, but I
want to report the things I
Bruce Momjian wrote:
Gavin Sherry wrote:
Attached is an updated patch, fixing a compile error which my compiler
didn't seem to detect/suffer from and incorporating fixes to problems
raised by Neil.
Thanks,
Gavin
OK, I have reviewed the patch. I think Tom is doing the same, but
I wrote the pg_dump bits, so I guess I can answer these...
And about restore, particularly to another machine, what do we do if the
tablespace can't be created in the location specified in the dump? The
tablespace creation fails, and all objects specified in that tablespace
also fail? Seems bad,
34 matches
Mail list logo
