Re: Big 7.1 open items

"Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)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