On Fri, Feb 12, 2016 at 12:55 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: > Very Good Catch. I think if we want to address this we can detect > the non-group leader transactions that tries to update the different > CLOG page (different from group-leader) after acquiring > CLogControlLock and then mark these transactions such that > after waking they need to perform CLOG update via normal path. > Now this can decrease the latency of such transactions, but I
I think you mean "increase". > think there will be only very few transactions if at-all there which > can face this condition, because most of the concurrent transactions > should be on same page, otherwise the idea of multiple-slots we > have tried upthread would have shown benefits. > Another idea could be that we update the comments indicating the > possibility of multiple Clog-page updates in same group on the basis > that such cases will be less and even if it happens, it won't effect the > transaction status update. I think either approach of those approaches could work, as long as the logic is correct and the comments are clear. The important thing is that the code had better do something safe if this situation ever occurs, and the comments had better be clear that this is a possible situation so that someone modifying the code in the future doesn't think it's impossible, rely on it not happening, and consequently introduce a very-low-probability bug. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
