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. Here are some ideas for brainstorming. It might prove useful to note that any given assertion involves tables A, B, C. If a transaction doesn't modify any of those tables then there's no need to run the assertion when the transaction commits, skipping acquisition of the assertion lock. Probably this can only be implemented for SQL-language assertions, but even so it might be worth considering. (Assertions in any other language would be checked by every transaction.) Another thought: at the initial run of the assertion, note which tables it locked, and record this as an OID array in the catalog row for the assertion; consider running the assertion only when those tables are touched. This doesn't work if the assertion code locks some tables when run under certain conditions and other tables under different conditions. But then this can be checked too: if an assertion lists in its catalog row that it involves tables A, B, C and then, under different conditions, it tries to acquire lock on table D, have the whole thing fail indicating that the assertion is misdeclared. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers