Re: lock_timeout GUC patch

Greg Stark <stark(at)mit(dot)edu> writes:
> we already have statement timeout it seems the natural easy to implement
> this is with more hairy logic to calculate the timeout until the next of the
> three timeouts should fire and set sigalarm. I sympathize with whoever tries
> to work that through though, the logic is hairy enough with just the two
> variables...but at least we know that sigalarm works or at least it had
> better...

Yeah, that code is ugly as sin already. Maybe there is a way to
refactor it so it can scale better? I can't help thinking of Polya's
inventor's paradox ("the more general problem may be easier to solve").

If we want to do it without any new system-call dependencies I think
that's probably the only way. I'm not necessarily against new
dependencies, if they're portable --- but it seems these aren't.

regards, tom lane