On Wed, Aug 10, 2016 at 8:26 PM, Greg Stark <st...@mit.edu> wrote: > On Wed, Aug 10, 2016 at 5:54 PM, Alexander Korotkov > <a.korot...@postgrespro.ru> wrote: > > Oh, I found that I underestimated complexity of async commit... :) > > Indeed. I think Tom's attitude was right even if the specific > conclusion was wrong. While I don't think removing async commit is > viable I think it would be a laudable goal if we can remove some of > the complication in it. I normally describe async commit as "just like > a normal commit but don't block on the commit" but it's actually a bit > more complicated. > > AIUI the additional complexity is that while async commits are visible > to everyone immediately other non-async transactions can be committed > but then be in limbo for a while before they are visible to others. So > other sessions will see the async commit "jump ahead" of any non-async > transactions even if those other transactions were committed first. > Any standbys will see the non-async transaction in the logs before the > async transaction and in a crash it's possible to lose the async > transaction even though it was visible but not the sync transaction > that wasn't. > > Complexity like this makes it hard to implement other features such as > CSNs. IIRC this already bit hot standby as well. I think it would be a > big improvement if we had a clear, well defined commit order that was > easy to explain and easy to reason about when new changes are being > made. >
Heikki, Ants, Greg, thank you for the explanation. You restored order in my personal world. Now I see that introduction of own sequence of CSN which is not equal to LSN makes sense. ------ Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
