Re: File versioning (was: Big 7.1 open items)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Zeugswetter Andreas SB <ZeugswetterA(at)Wien(dot)Spardat(dot)at>
Cc: Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Jan Wieck <JanWieck(at)yahoo(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, "Ross J(dot) Reedstrom" <reedstrm(at)rice(dot)edu>, Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>
Subject: Re: File versioning (was: Big 7.1 open items)
Date: 2000-06-26 14:42:31
Message-ID: 17015.962030551@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Zeugswetter Andreas SB <ZeugswetterA(at)Wien(dot)Spardat(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Zeugswetter Andreas SB 2000-06-26 14:51:32 AW: physical backup of PostgreSQL
Previous Message Philip Warner 2000-06-26 14:30:30 Re: Proposal: More flexible backup/restore via pg_dump