On Dec18, 2013, at 20:39 , Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > Andres Freund wrote: >> On 2013-12-18 13:44:15 -0300, Alvaro Herrera wrote: >>> Heikki Linnakangas wrote: >>> >>>> Ah, I see. You don't need to block anyone else from modifying the >>>> table, you just need to block anyone else from committing a >>>> transaction that had modified the table. So the locks shouldn't >>>> interfere with regular table locks. A ShareUpdateExclusiveLock on >>>> the assertion should do it. >>> >>> Causing serialization of transaction commit just because a single >>> assertion exists in the database seems too much of a hit, so looking for >>> optimization opportunities seems appropriate. >> >> It would only force serialization for transactions that modify tables >> covered by the assert, that doesn't seem to bad. Anything covered by an >> assert shoulnd't be modified frequently, otherwise you'll run into major >> performance problems. > > Well, as presented there is no way (for the system) to tell which tables > are covered by an assertion, is there? That's my point.
Well, we *do* know that after executing the assertion, since we know (or at least can track) which tables the assertion touches. I wonder if we couldn't lazily enable SERIALIZED semantics for those tables only, and do so while we evaluate the assertion. So, before evaluating the assertion, we would change the isolation level to SERIALIZABLE. We'd then have to make sure that we detect any conflicts which we would have detected had the isolation level been SERIALIZABLE all along *and* which somehow involve the assertion. Simply changing the isolation level should suffice to detect cases where we read data modified by concurrent transactions. To also detect cases where we write data read by concurrent transactions, we'd have to watch for tuples which were modified by our own transaction. For these tuples, we'd have to verify do what we would have done had we already been in SERIALIZABLE mode when the modification occurred. That means checking for SIREAD locks taken by other transactions, on the tuple and all relevant index pages (plus all corresponding coarser-grained entities like the tuples's page, the table, …). best regards, Florian Pflug -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers