
> Besides which, OID alone doesn't give us a possibility of file
> versioning, and as I commented to Vadim I think we will want that,
> WAL or no WAL.  So it seems to me the two viable choices are
> unique-id or OID+version-number.  Either way, the file-naming behavior
> should be the same across all platforms.

I do not think the only problem of a failing rename of "temp" to "new" 
on startup rollforward is issue enough to justify the additional complexity
a version implys.
Why not simply abort startup of postmaster in such an event and let the 
dba fix it. There can be no data loss.

If e.g. the permissions of the directory are insufficient we will want to
abort 
startup anyway, no?

Andreas

Mon, 26 Jun 2000 10:09:13 +0200
Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
File versioning (was: Big 7.1 open items) 
> -----Original Message-----
> From: Zeugswetter Andreas SB
> 
> > Besides which, OID alone doesn't give us a possibility of file
> > versioning, and as I commented to Vadim I think we will want that,
> > WAL or no WAL.  So it seems to me the two viable choices are
> > unique-id or OID+version-number.  Either way, the file-naming behavior
> > should be the same across all platforms.
> 
> I do not think the only problem of a failing rename of "temp" to "new" 
> on startup rollforward is issue enough to justify the additional 
> complexity
> a version implys.

Hmm,I've always mentioned about usual rollback and never mentioned
about rollforward on this topic AFAIR. Could you tell me what you mean
by * on startup rollforward* ?

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

Mon, 26 Jun 2000 19:08:54 +0900
"Hiroshi Inoue" <Inoue@seiren.co.jp>
RE: File versioning (was: Big 7.1 open items) 
Zeugswetter Andreas SB <ZeugswetterA@Wien.Spardat.at> writes:
> I do not think the only problem of a failing rename of "temp" to "new" 
> on startup rollforward is issue enough to justify the additional complexity
> a version implys.

If that were the only reason for it then I wouldn't feel it was so
essential.  However, it will also let us fix CLUSTER, vacuuming of
indexes, ALTER TABLE DROP COLUMN with physical removal of the column,
etc etc.  Making the world safe for rollbackable RENAME/DROP/TRUNCATE
TABLE is just one of the benefits.

Versioning also eliminates a whole host of problems at the bufmgr/smgr
level that are caused by having to cope with relation files getting
renamed out from under you.  We have painfully eliminated some of these
problems over the past couple of years by ad-hoc, ugly techniques like
flushing the buffer cache when doing a rename.  But who's to say there
are not more such bugs left?

In short, I think versioning is far *less* complex, not to mention more
reliable, than the kluges we need to use to work around the lack of it.

			regards, tom lane

Mon, 26 Jun 2000 10:42:31 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: File versioning (was: Big 7.1 open items) 