Re: COMMIT NOWAIT Performance Option

On Tue, Feb 27, 2007 at 10:49:32AM +0000, Simon Riggs wrote:
> > I dislike introducing new nonstandard syntax ("Oracle compatible" is not
> > standard). If we did this I'd vote for control via a GUC setting only;
> > I think that is more useful anyway, as an application can be made to run
> > with such a setting without invasive source code changes.
>
> OK.
>
> Having read through all of the above things again, ISTM that we should
> make this functionality available by a new GUC commit_fsync_delay, which
> must be set explicitly > 0 before this feature can be used at all. If I
> confused Tom by using commit_delay, then I'll confuse others also and
> group commit and deferred fsync are different techniques with different
> robustness guarantees. When enabled it should have a clear message in
> the log to show that some commits might be using commit_nowait.
>
> I'd even welcome a more descriptive term that summed up the relaxed
> transaction guarantee implied by the use of the deferred fsync
> technique. Perhaps even a very explicit USERSET GUC:
>
> transaction_guarantee = on (default) | off

So would you set commit_fsync_delay on a per-transaction basis? That
doesn't make much sense to me... I guess I'm not seeing how you would
explicitly mark transactions that you didn't want to fsync immediately.
--
Jim Nasby jim(at)nasby(dot)net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)