Re: CommitDelay performance improvement

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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.

> 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.

regards, tom lane