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