Skip site navigation (1) Skip section navigation (2)

RE: Big 7.1 open items

From: "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>
To: "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM>, "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Thomas Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu>, "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>
Subject: RE: Big 7.1 open items
Date: 2000-06-23 03:49:48
Message-ID: 000101bfdcc6$13b186a0$ (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
> -----Original Message-----
> From: Mikheev, Vadim [mailto:vmikheev(at)SECTORBASE(dot)COM]
> > > 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.
> Ok, ok. Let's use *unique* file name for each table version.
> But after thinking, seems that I agreed with Hiroshi about using
> *some unique id* for file names instead of oid+version: we could use
> just DB' OID + this unique ID in log records to find table file - just
> 8 bytes.
> So, add me to Hiroshi' camp... if Hiroshi is ready to implement new file
> naming -:)

I've thought e.g. newfileid() like newoid() using pg_variable.
Other smarter ways ? 


Hiroshi Inoue

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2000-06-23 05:50:47
Subject: Re: PGSQL internals question...
Previous:From: Paul CaskeyDate: 2000-06-23 03:31:59
Subject: 64-bit sequences

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group