One good thing about advisory locks having been in contrib was that they didn't affect anyone who didn't actually install the module. Now that we've put those functions in core, I wonder whether we don't need to face up to the possibility of malicious use. For instance, it's not very hard to create a DoS situation by running the system out of shared lock table space:
regression=# select pg_advisory_lock(x) from generate_series(1,1000000) x; WARNING: out of shared memory ERROR: out of shared memory HINT: You may need to increase max_locks_per_transaction. regression=# and once you've done that about the only fix is to quit your backend :-( The brute force answer is to make those functions superuser-only, but I wonder if there is a better way. Perhaps we could just deny public execute access on them by default, and let admins grant the privilege to whom they trust. Or we could try to do something about limiting the number of such locks that can be granted, but that seems nontrivial to tackle at such a late stage of the devel cycle. Thoughts? regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster