Re: Strange Windows problem, lock_timeout test request

Boszormenyi Zoltan <zb(at)cybertec(dot)at> writes:
> 2013-03-15 18:53 keltezssel, 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.

> 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