Re: SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5

From: Boszormenyi Zoltan <zb(at)cybertec(dot)at>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Hans-Juergen Schoenig <postgres(at)cybertec(dot)at>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5
Date: 2009-05-11 17:56:00
Message-ID: 4A0866B0.20409@cybertec.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane írta:
> Boszormenyi Zoltan <zb(at)cybertec(dot)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/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-05-11 18:01:34 Re: SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5
Previous Message Tom Lane 2009-05-11 17:42:01 Re: SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5