Re: FW: [PATCHES] relation filename patch

On Mon, May 01, 2000 at 12:06:14PM +0900, Hiroshi Inoue wrote:
> > -----Original Message-----
> > From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
> > Sent: Monday, May 01, 2000 11:36 AM
> > To: Hiroshi Inoue
> > Cc: Bruce Momjian
> > Subject: Re: FW: [PATCHES] relation filename patch
> > 
> > 
> > [Charset iso-8859-1 unsupported, filtering to ASCII...]
> > > The patch seems to be a trial patch for evaluatuon.
> > > 
> > 
> > I see, it appends the oid on the end of the file name.  Seems like an
> > interesting idea.  That would help in some cases, but it seems we agreed
> > on a more general sequence number for relations so we can fix some of
> > our other problems where the mapping between table and file names breaks
> > down.  Sometimes we want two files for the same relation, and have
> > different onces be visible to different backends.  In those cases, the
> > oid does not change.  We could add the oid _and_ a sequence number to
> > fix that.
> >

Well, it could be just the sequence number, if it had the properties of
being unique across all backends. I didn't use the existing seq. number
code, (used for temp tables?) because it seems to be reset at transaction
start. Besides, that discussion happened _after_ I'd finished the
patch. ;-) I was just holding on to it (from about the first 7.0 freeze)
to not distract anyone.

> 
> Yes but it would be easily changed.
> If I remeber correctly,there are only two places that require a Rule
> for generating the filename in his implementation,

That's right, and both of those are for initializing the filename of a
new relation: nothing in the backend, deduces the filename of an existing
relation: it's always looked up.

I seem to recall that the cases where two files are needed are to remove
the drop/recreate cycle from CLUSTER and index rebuilding, particuarly
to make them robust to interuption, particularly as to the rename()
of the underlying file. With my current patch, that could be done (at
2x disk space cost) by building the second version of the table under a
different relname, perhaps as a temp relation even, and then UPDATE the
pg_class entry to point at the new file, and have the temp relation point
to the old file, as the last step. None of the DB code needs to have the
filename in sync, so just leave it 'wrong', or fix it at vacuum time,
when you get a table lock anyway.

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