Tom Lane wrote: > "Simon Riggs" <[EMAIL PROTECTED]> writes: > > COMMIT NOWAIT can co-exist with the normal form of COMMIT and does not > > threaten the consistency or robustness of other COMMIT modes. Read that > > again and think about it, before we go further, please. > > I read that, and thought about it, and don't think I believe it. The > problem is that there are more interconnections between different > transactions than you're allowing for. In particular you need to > justify that the behavior is safe for non-transactional operations like > btree page splits and pg_clog buffer page writes. The idea that's > particularly bothering me at the moment is that after a system crash, > we might come back up in a state where a NOWAIT transaction appears > committed when its updates didn't all get to disk. "Database corrupt" > is a situation that threatens all your transactions... > > > New commit mode is available by explicit command, or as a default > > setting that will be applied to all COMMITs, or both. > > 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.
Agreed on the GUC-only. I don't see many people using the per-COMMIT setting without wanting it to be for many transactions in the session. (And, YES, I am VERY excited we are getting this feature.) -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster