Re: Cost limited statements RFC

On Thu, May 23, 2013 at 8:27 PM, Greg Smith <greg(at)2ndquadrant(dot)com> wrote:
> The main unintended consequences issue I've found so far is when a cost
> delayed statement holds a heavy lock. Autovacuum has some protection
> against letting processes with an exclusive lock on a table go to sleep. It
> won't be easy to do that with arbitrary statements. There's a certain
> amount of allowing the user to shoot themselves in the foot here that will
> be time consuming (if not impossible) to eliminate. The person who runs an
> exclusive CLUSTER that's limited by statement_cost_delay may suffer from
> holding the lock too long. But that might be their intention with setting
> the value. Hard to idiot proof this without eliminating useful options too.

Why not make the delay conditional on the amount of concurrency, kinda
like the commit_delay? Although in this case, it should only count
unwaiting connections.

That way, if there's a "delay deadlock", the delay gets out of the way.