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

From: Alfred Perlstein <bright(at)wintelcom(dot)net>
To: Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>
Cc: vmikheev(at)SECTORBASE(dot)COM, peter_e(at)gmx(dot)net, pgsql-hackers(at)postgresql(dot)org
Subject: Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)
Date: 2000-11-11 03:19:25
Message-ID: 20001110191925.K11449@fw.wintelcom.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)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(at)wintelcom(dot)net|alfred(at)freebsd(dot)org]
"I have the heart of a child; I keep it in a jar on my desk."

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Philip Warner 2000-11-11 03:44:29 Re: Unhappy thoughts about pg_dump and objects inherited from template1
Previous Message Mark Hollomon 2000-11-11 02:52:06 Re: Unhappy thoughts about pg_dump and objects inherited from template1