Re: COMMIT NOWAIT Performance Option
От | Tom Lane |
---|---|
Тема | Re: COMMIT NOWAIT Performance Option |
Дата | |
Msg-id | 10498.1172549047@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | COMMIT NOWAIT Performance Option ("Simon Riggs" <simon@2ndquadrant.com>) |
Ответы |
Re: COMMIT NOWAIT Performance Option
Re: COMMIT NOWAIT Performance Option |
Список | pgsql-hackers |
"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. regards, tom lane
В списке pgsql-hackers по дате отправления: