* Bruce Momjian <pgman@candle.pha.pa.us> [001111 00:16] wrote:
> > * 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?
>
> The default is to sync on commit, but we need to give people options of
> several seconds delay for performance reasons. Inforimx calls it
> buffered logging, and it is used by most of the sites I know because it
> has much better performance that sync on commit.
>
> If the machine crashes five seconds after commit, many people don't have
> a problem with just re-entering the data.
We have several critical tables and running certain updates/deletes/inserts
on them in async mode worries me. Would it be possible to add a
'set' command to force a backend into fsync mode and perhaps back
into non-fsync mode as well?
What about setting an attribute on a table that could mean
a) anyone updating me better fsync me.
b) anyone updating me better fsync me as well as fsyncing anything else they touch.
I swear one of these days I'm going to get more familiar with the
codebase and actually submit some useful patches for the backend.
:(
--
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
