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]>

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

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Reply via email to