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 [EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly