Re: Strange Windows problem, lock_timeout test request

2013-03-16 17:42 keltezéssel, Tom Lane írta:
> Boszormenyi Zoltan <zb(at)cybertec(dot)at> writes:
>> 2013-03-15 18:53 keltezéssel, Tom Lane írta:
>>> Also, I'm not really enamored of the choice to use List* infrastructure
>>> for enable_timeouts().
>> Changed. However, the first member of the structure is
>> "TimeoutId id" and a sensible end-of-array value can be -1.
>> Some versions of GCC (maybe other compilers, too) complain
>> if a constant is assigned to an enum which is outside of the
>> declared values of the enum. So I added a "NO_TIMEOUT = -1"
>> to enum TimeoutId. Comments?
> I was thinking more of having array pointer and count parameters, ie
> enable_timeouts(TimeoutParams *timeouts, int n)
> I guess we could do it with sentinels instead but not sure that's
> better.
>
> The sentinel approach might be all right if there was another reason
> to have an "invalid" value in the enum, but I'm not seeing one ATM.

Stephen Frost was against the array pointer/count variant,
it was done that way earlier. Let me redo it again. :-)

>
>> I hope the way I did it is right. I factored out the core of
>> StatementCancelHandler() into a common function that can
>> be used by the lock_timeout interrupt as its timeout callback
>> function. Now the code doesn't need PGSemaphoreTimedLock().
> Hm, not needing PGSemaphoreTimedLock at all is an improvement for
> sure. Don't have time right now to look closer though.
>
> regards, tom lane
>
>

--
----------------------------------
Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt, Austria
Web: http://www.postgresql-support.de
http://www.postgresql.at/