Re: COMMIT NOWAIT Performance Option

Tom Lane wrote:
> "Simon Riggs" <simon@2ndquadrant.com> 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  <bruce@momjian.us>          http://momjian.us EnterpriseDB
http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +