Re: Fix for RENAME

Seems Vadim's new storage manager for 7.2 would be the way to go.

I think he is going to have everything in one file.

[ Charset ISO-8859-1 unsupported, converting... ]

-----Original Message-----
From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]

Can someone comment on this?

It seems to me that we have to reach some consensus in
order to get a standard transactional control mechanism
to change the allocation of table files. Probably we would
have to separate things into 2 parts.

1) Where to allocate tables -- we would need some encapsulation
like tablespace. It would be better to be handled differently by
each storage manager. Note that tablespace is only an encap-
sulation and doesn't necessarily mean that of Oracle.
2) Where tables are allocated -- only specific strorage manager
knows the meaing and everything would be treated internally.

Under current (file per table) storage manager,#1 isn't necessarily
needed for the implementaion of #2 and Ross has already tried it.
If we could get some consensus on the future direction of 1)2),
we would be able to apply his implementation.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

[ Charset ISO-8859-1 unsupported, converting... ]

-----Original Message-----
From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]

I'm now inclined to introduce a new system relation to store
the physical path name. It could also have table(data)space
information in the (near ?) future.
It seems better to separate it from pg_class because table(data?)
space may change the concept of table allocation.

Why not just put it in pg_class?

Not sure,it's only my feeling.
Comments please,everyone.

We have taken a practical way which doesn't break file per table
assumption in this thread and it wouldn't so difficult to implement.
In fact Ross has already tried it.

However there was a discussion about data(table)space for
months ago and currently a new discussion is there.
Judging from the previous discussion,I can't expect so much
that it could get a practical consensus(How many opinions there
were). We can make a practical step toward future by encapsulating
the information of table allocation. Separating table alloc info from
pg_class seems one of the way.
There may be more essential things for encapsulation.

Comments ?

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

-- 
Bruce Momjian                        |  http://www.op.net/~candle
pgman@candle.pha.pa.us               |  (610) 853-3000
+  If your life is a hard drive,     |  830 Blythe Avenue
+  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

-----Original Message-----
From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]

Can someone comment on this?

It seems to me that we have to reach some consensus in
order to get a standard transactional control mechanism
to change the allocation of table files. Probably we would
have to separate things into 2 parts.

1) Where to allocate tables -- we would need some encapsulation
like tablespace. It would be better to be handled differently by
each storage manager. Note that tablespace is only an encap-
sulation and doesn't necessarily mean that of Oracle.
2) Where tables are allocated -- only specific strorage manager
knows the meaing and everything would be treated internally.

Under current (file per table) storage manager,#1 isn't necessarily
needed for the implementaion of #2 and Ross has already tried it.
If we could get some consensus on the future direction of 1)2),
we would be able to apply his implementation.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

Bah, while editing myself out of the To: list, I botched the mailing lists
address. Here it is, for everyone else.

Ross
----- Forwarded message from "Ross J. Reedstrom" <reedstrm@rice.edu> -----

On Sun, Jun 11, 2000 at 11:14:06PM -0400, Bruce Momjian wrote:

Seems Vadim's new storage manager for 7.2 would be the way to go.

I think he is going to have everything in one file.

Might I remind everyone that that current code is actually buggy on
NT: since the NTFS is case-insensitive/case-preserving, two tables
"fred" and "Fred" attempt to create the same file to store into.

Hiroshi had a version of my patch without the silly messing with the
relcache, that passed all the regression tests. Perhaps we should put
that in as an NT bug fix, while we wait for bigger and better things?
I have noticed a lot more activity on the mailing lists mentioning
looking at the NT port.

The patch would need to be tweaked a little: ALTER TABLE RENAME becomes
less intrusive (a mere update of relname in pg_class) and completely
under MVCC and transaction control. VACUUM may need touching to find
renamed tables and fix their physical table name then, since it's already
got the locks needed, if we want to maintain consistency of the mostly
human readable filename <-> tablename relation. It could also be fixed
up by a dump/restore, since the physical filename is generated at table
creation time.

Ross
--
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005

----- End forwarded message -----

-----Original Message-----
From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]

Seems Vadim's new storage manager for 7.2 would be the way to go.

I think he is going to have everything in one file.

Probably Vadim would have to change something around storage
manager before 7.1 in his WAL implementation. So what should/
could we do for 7.1 ? If Vadim would do/has done everything,it
should be clearly mentioned. Otherwise other people would waste
their time.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp