Re: Big 7.1 open items

On Thu, Jun 15, 2000 at 07:53:52PM -0400, Tom Lane wrote:
> "Ross J. Reedstrom" <reedstrm(at)rice(dot)edu> writes:
> > On Thu, Jun 15, 2000 at 03:11:52AM -0400, Tom Lane wrote:
> >> "Ross J. Reedstrom" <reedstrm(at)rice(dot)edu> writes:
> >>>> Any strong objections to the mixed relname_oid solution?
> >>
> >> Yes!
>
> > The plan here was to let VACUUM handle renaming the file, since it
> > will already have all the necessary locks. This shortens the window
> > of confusion. ALTER TABLE RENAME doesn't happen that often, really -
> > the relname is there just for human consumption, then.
>
> Yeah, I've seen tons of discussion of how if we do this, that, and
> the other thing, and be prepared to fix up some other things in case
> of crash recovery, we can make it work with filename == relname + OID
> (where relname tracks logical name, at least at some remove).
>
> Probably. Assuming nobody forgets anything.

I agree, it seems a major undertaking, at first glance. And second. Even
third. Especially for someone who hasn't 'earned his spurs' yet. as
it were.

> I'm just trying to point out that that's a huge amount of pretty
> delicate mechanism. The amount of work required to make it trustworthy
> looks to me to dwarf the admin tools that Bruce is complaining about.
> And we only have a few people competent to do the work. (With all
> due respect, Ross, if you weren't already aware of the implications
> for mdblindwrt, I have to wonder what else you missed.)

Ah, you knew that comment would come back to haunt me (I have a
tendency to think out loud, even if checking and coming back latter
would be better;-) In fact, there's no problem, and never was, since the
buffer->blind.relname is filled in via RelationGetPhysicalRelationName,
just like every other path that requires direct file access. I just
didn't remember that I had in fact checked it (it's been a couple months,
and I just got back from vacation ;-)

Actually, Once I re-checked it, the code looked very familiar. I had
spent time looking at the blind write code in the context of getting
rid of the only non-startup use of GetRawDatabaseInfo.

As to missing things: I'm leaning heavily on Bruce's previous
work for temp tables, to seperate the two uses of relname, via the
RelationGetRelationName and RelationGetPhysicalRelationName. There are
102 uses of the first in the current code (many in elog messages), and
only 11 of the second. If I'd had to do the original work of finding
every use of relname, and catagorizing it, I agree I'm not (yet) up to
it, but I have more confidence in Bruce's (already tested) work.

>
> Filename == OID is so simple, reliable, and straightforward by
> comparison that I think the decision is a no-brainer.
>

Perhaps. Changing the label of the file on disk still requires finding
all the code that assumes it knows what that name is, and changing it.
Same work.

> If we could afford to sink unlimited time into this one issue then
> it might make sense to do it the hard way, but we have enough
> important stuff on our TODO list to keep us all busy for years ---
> I cannot believe that it's an effective use of our time to do this.
>

The joys of Open Development. You've spent a fair amount of time trying
to convince _me_ not to waste my time. Thanks, but I'm pretty bull headed
sometimes. Since I've already done something of the work, take a look
at what I've got, and then tell me I'm wasting my time, o.k.?

>
> > Hmm, what's all this with functions in catalog.c that are only called by
> > smgr/md.c? seems to me that anything having to do with physical storage
> > (like the path!) belongs in the smgr abstraction.
>
> Yeah, there's a bunch of stuff that should have been implemented by
> adding new smgr entry points, but wasn't. It should be pushed down.
> (I can't resist pointing out that one of those things is physical
> relation rename, which will go away and not *need* to be pushed down
> if we do it the way I want.)
>

Oh, I agree completely. In fact, As I said to Hiroshi last time this came
up, I think of the field in pg_class an an opaque token, to be filled in
by the smgr, and only used by code further up to hand back to the smgr
routines. Same should be true of the buffer->blind struct.

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