On 23/09/10 02:14, Kevin Grittner wrote:
There is a rub on the other point, though. Without transaction information you have no way of telling whether TN committed before T0, so you would need to assume that it did. So on this count, there is bound to be some increase in false positives leading to transaction rollback. Without more study, and maybe some tests, I'm not sure how significant it is. (Actually, we might want to track commit sequence somehow, so we can determine this with greater accuracy.)
I'm confused. AFAICS there is no way to tell if TN committed before T0 in the current patch either.
But wait, the bigger problems are yet to come. The other way we can detect conflicts is a read by a serializable transaction noticing that a different and overlapping serializable transaction wrote the tuple we're trying to read. How do you propose to know that the other transaction was serializable without keeping the SERIALIZABLEXACT information?
Hmm, I see. We could record which transactions were serializable in a new clog-like structure that wouldn't exhaust shared memory.
And how do you propose to record the conflict without it?
I thought you just abort the transaction that would cause the conflict right there. The other transaction is committed already, so you can't do anything about it anymore.
Finally, this would preclude some optimizations which I *think* will pay off, which trade a few hundred kB more of shared memory, and some additional CPU to maintain more detailed conflict data, for a lower false positive rate -- meaning fewer transactions rolled back for hard-to-explain reasons. This more detailed information is also what seems to be desired by Dan S (on another thread) to be able to log the information needed to be able to reduce rollbacks.
Ok, I think I'm ready to hear about those optimizations now :-). -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
