RE: Big 7.1 open items - Mailing list pgsql-hackers

From Mikheev, Vadim
Subject RE: Big 7.1 open items
Date
Msg-id 8F4C99C66D04D4118F580090272A7A23018C31@SECTORBASE1
Whole thread Raw
In response to Big 7.1 open items  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses RE: Big 7.1 open items
List pgsql-hackers
> > 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 -:)

> > 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.

I always thought so.

> pg_control is not so good --- if it gets corrupted, how do 
> you recover?

Impossible to recover anyway - pg_control keeps last checkpoint pointer,
required for recovery. That's why Oracle recommends (requires?) at least
two copies of control file (and log too).
But what if log gets corrupted? Or file system (lost symlinks etc)?
One will have to use backup...

Vadim


pgsql-hackers by date:

Previous
From: "Randall Parker"
Date:
Subject: Re: Thoughts on multiple simultaneous code page support
Next
From: Brook Milligan
Date:
Subject: NOTICES about portals