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