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

Hiroshi Inoue [mailto:Inoue@seiren.co.jp] wrote:

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* ?

situation:
$ alter table ...

db crash before rename is done but rest was ok.

$ startup

rollforward tx log which has the open entry for the rename table

Andreas

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

Zeugswetter Andreas SB wrote:

Hiroshi Inoue [mailto:Inoue@seiren.co.jp] wrote:

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* ?

situation:
$ alter table ...

db crash before rename is done but rest was ok.

$ startup

Doesn't above *startup* mean the startup of transaction recovery ?
Because I don't know Vadim's implementation about WAL well,I've
never taken WAL into account in this topic. I've always discussed
about usual rollback and so the problem you've pointed out is not
my point of discussion.
Seems we have discussed this topic from different POV.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp