Re: SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5 - Mailing list pgsql-hackers

From Boszormenyi Zoltan
Subject Re: SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5
Date
Msg-id 4A0866B0.20409@cybertec.at
Whole thread Raw
In response to Re: SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane írta:
> Boszormenyi Zoltan <zb@cybertec.at> writes:
>   
>> Would the "lock_timeout" work for all to be acquired locks individually,
>> or all of them combined for the statement? The individual application
>> of the timeout for every locks individually wouldn't be too nice.
>>     
>
> I think the way you're describing would be both harder to implement
> and full of its own strange traps.
>   

Why?

   PGSemaphoreTimedLock(..., struct timespec *timeout)   {         ...         gettimeofday(&tv1, NULL);
semtimedop(..., timeout);         gettimeofday(&tv2, NULL);
 
         <decrease *timeout with the difference of tv1 and tv2>   }

Next call will use the decreased value.
Either all locks are acquired in the given time, or the next try will
timeout (error) or there are still locks and the timeout went down to
or below zero (error). Why is it hard?


>             regards, tom lane
>
>   


-- 
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/



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5
Next
From: Tom Lane
Date:
Subject: Re: SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5