Re: lock_timeout GUC patch

Tom Lane írta:
> 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.
>   

Okay, after reading google it seems you're right that OS X lacks
sem_timedwait(). How about adding a configure check for semtimedop()
and sem_timedwait() and if they don't exist set a compile time flag
(HAVE_XXX) and in this case PGSemaphoreTimedLock() would
behave the same as PGSemaphoreLock() and have an assign_*()
function that tells the user that the timeout functionality is missing?
We have precedent for the missing functionality with e.g.
effective_io_concurrency and ereport() is also allowed in such
functions, see assign_transaction_read_only().

Best regards,
Zoltán Böszörményi

-- 
Bible has answers for everything. Proof:
"But let your communication be, Yea, yea; Nay, nay: for whatsoever is more
than these cometh of evil." (Matthew 5:37) - basics of digital technology.
"May your kingdom come" - superficial description of plate tectonics

----------------------------------
Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH
http://www.postgresql.at/