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 20001110191925.K11449@fw.wintelcom.net
Whole thread Raw
In response to RE: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)  (Tatsuo Ishii <t-ishii@sra.co.jp>)
Responses Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)  (Tatsuo Ishii <t-ishii@sra.co.jp>)
List pgsql-hackers
* Tatsuo Ishii <t-ishii@sra.co.jp> [001110 18:42] wrote:
> > 
> > Yes, though we can change this. We also can implement now
> > feature that Bruce wanted so long and so much -:) -
> > fsync log not on each commit but each ~ 5sec, if
> > losing some recent commits is acceptable.
> 
> Sounds great.

Not really, I thought an ack on a commit would mean that the data
is actually in stable storage, breaking that would be pretty bad
no?  Or are you only talking about when someone is running with
async Postgresql?

Although this doesn't have an effect on my current application,
when running Postgresql with sync commits and WAL can one expect
the old behavior, ie. success only after data and meta data (log)
are written?

Another question I had was what would the effect of a mid-fsync
crash have on a system using WAL, let's say someone yanks the
power while the OS in the midst of fsync, will all be ok?

-- 
-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: Tatsuo Ishii
Date:
Subject: RE: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)
Next
From: Philip Warner
Date:
Subject: Re: Unhappy thoughts about pg_dump and objects inherited from template1