On 9/21/06, Tom Lane <[EMAIL PROTECTED]> wrote:
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:
It's much more likely to accidentally bork yourself.
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.
I vote for locking down to superuser access (lets be frank here: I would estimate 90%+ database installatons run with the application as root) so we are not losing much. I honestly think exhausting the lock space should raise a fatal, not an error. This gives a chance for recovery without a hard reset. Any other limitation would be fine, now or later, just please don't slow them down! (advisory locks are extremely fast). merlin ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
