Re: COMMIT NOWAIT Performance Option

Tom Lane wrote:
> "Simon Riggs" <simon(at)2ndquadrant(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +