> 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