Re: lock_timeout GUC patch - Mailing list pgsql-hackers

From Tom Lane
Subject Re: lock_timeout GUC patch
Date
Msg-id 26218.1263956855@sss.pgh.pa.us
Whole thread Raw
In response to Re: lock_timeout GUC patch  (Greg Stark <stark@mit.edu>)
Responses Re: lock_timeout GUC patch  (Boszormenyi Zoltan <zb@cybertec.at>)
List pgsql-hackers
Greg Stark <stark@mit.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


pgsql-hackers by date:

Previous
From: "Greg Sabino Mullane"
Date:
Subject: Re: MySQL-ism help patch for psql
Next
From: "J. Greg Davidson"
Date:
Subject: Re: xml2 still essential for us