> If we bit the bullet and restricted ourselves to numeric filenames then
> the log would need just four numeric values:
> 	database OID
> 	tablespace OID

Is someone going to implement it for 7.1?

> 	relation OID
> 	relation version number

I believe that we can avoid versions using WAL...

> (this set of 4 values would also be an smgr file reference token).
> 16 bytes/log entry looks much better than 64.
> 
> At the moment I can recall the following opinions:
> 
> Pure OID filenames: Thomas, Tom, Marc, Peter E.

+ me.

But what about LOCATIONs? I object using environment and think that
locations
must be stored in pg_control..?

Vadim

Wed, 21 Jun 2000 16:00:17 -0700
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM>
RE: Big 7.1 open items 
> -----Original Message-----
> From: Mikheev, Vadim [mailto:vmikheev@SECTORBASE.COM]
> 
> > If we bit the bullet and restricted ourselves to numeric filenames then
> > the log would need just four numeric values:
> > 	database OID
> > 	tablespace OID
> 
> Is someone going to implement it for 7.1?
> 
> > 	relation OID
> > 	relation version number
> 
> I believe that we can avoid versions using WAL...
>

How to re-construct tables in place ?
Is the following right ?
1) save the content of current table to somewhere
2) shrink the table and related indexes
3) reload the saved(+some filtering) content

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

Thu, 22 Jun 2000 09:16:30 +0900
"Hiroshi Inoue" <Inoue@tpf.co.jp>
RE: Big 7.1 open items 
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM> writes:
>> relation OID
>> relation version number

> I believe that we can avoid versions using WAL...

I don't think so.  You're basically saying that
	1. create file 'new'
	2. delete file 'old'
	3. rename 'new' to 'old'
is safe as long as you have a redo log to ensure that the rename
happens even if you crash between steps 2 and 3.  But crash is not
the only hazard.  What if step 3 just plain fails?  Redo won't help.

I'm having a hard time inventing really plausible examples, but a
slightly implausible example is that someone chmod's the containing
directory -w between steps 2 and 3.  (Maybe it's not so implausible
if you assume a crash after step 2 ... someone might have left the
directory nonwritable while restoring the system.)

If we use file version numbers, then the *only* thing needed to
make a valid transition between one set of files and another is
a commit of the update of pg_class that shows the new version number
in the rel's pg_class tuple.  The worst that can happen to you in
a crash or other failure is that you are unable to get rid of the
set of files that you don't want anymore.  That might waste disk
space but it doesn't leave the database corrupted.

> But what about LOCATIONs? I object using environment and think that
> locations must be stored in pg_control..?

I don't like environment variables for this either; it's just way too
easy to start the postmaster with wrong environment.  It still seems
to me that relying on subdirectory symlinks is a good way to go.
pg_control is not so good --- if it gets corrupted, how do you recover?
symlinks can be recreated by hand if necessary, but...

			regards, tom lane

Wed, 21 Jun 2000 23:14:50 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Big 7.1 open items 