Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c) - Mailing list pgsql-hackers

From Alfred Perlstein
Subject Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)
Date
Msg-id 20001111230050.Y11449@fw.wintelcom.net
Whole thread Raw
In response to Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
* Tom Lane <tgl@sss.pgh.pa.us> [001111 12:06] wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> >> I have to agree with Alfred here: this does not sound like a feature,
> >> it sounds like a horrid hack.  You're giving up *all* consistency
> >> guarantees for a performance gain that is really going to be pretty
> >> minimal in the WAL context.
> 
> > It does not give up consistency.  The db is still consistent, it is just
> > consistent from a few seconds ago, rather than commit time.
> 
> No, it isn't consistent.  Without the fsync you don't know what order
> the kernel will choose to plop down WAL log blocks in; you could end up
> with a corrupt log.  (Actually, perhaps that could be worked around if
> the log blocks are suitably marked so that you can tell where the last
> sequentially valid one is.  I haven't looked at the log structure in
> any detail...)

This could be fixed by using O_FSYNC on the open call for the WAL
data files on *BSD, i'm not sure of the sysV equivelant, but I know
it exists.

-- 
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
"I have the heart of a child; I keep it in a jar on my desk."


pgsql-hackers by date:

Previous
From: Philip Warner
Date:
Subject: Re: Coping with 'C' vs 'newC' function language names
Next
From: Dave
Date:
Subject: can't insert "³\" as varchar in 7.0.2 and 7.1