Re: CommitDelay performance improvement

> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > My idea would be to let committing backends return "COMMIT" to the user,
> > and set a need_fsync flag that is guaranteed to cause an fsync within X
> > milliseconds.  This way, if other backends commit in the next X
> > millisecond, they can all use one fsync().
> 
> Guaranteed by what?  We have no mechanism available to make an fsync
> happen while the backend is waiting for input.

We would need a separate binary that can look at shared memory and fsync
is someone requested it.  Again, nothing for 7.1.X.

> > Now, I know many will complain that we are returning commit while not
> > having the stuff on the platter.
> 
> I think that's unacceptable on its face.  A remote client may take
> action on the basis that COMMIT was returned.  If the server then
> crashes, the client is unlikely to realize this for some time (certainly
> at least one TCP timeout interval).  It won't look like a "milliseconds
> later" situation to that client.  In fact, the client might *never*
> realize there was a problem; what if it disconnects after getting the
> COMMIT?
> 
> If the dbadmin thinks he doesn't need fsync before commit, he'll likely
> be running with fsync off anyway.  For the ones who do think they need
> fsync, I don't believe that we get to rearrange the fsync to occur after
> commit.

I can see someone wanting some fsync, but not take the hit.  My argument
is that having this ability, there would be no need to turn off fsync.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026