Re: Strange Windows problem, lock_timeout test request - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Strange Windows problem, lock_timeout test request
Date
Msg-id 22733.1363452171@sss.pgh.pa.us
Whole thread Raw
In response to Re: Strange Windows problem, lock_timeout test request  (Boszormenyi Zoltan <zb@cybertec.at>)
Responses Re: Strange Windows problem, lock_timeout test request  (Boszormenyi Zoltan <zb@cybertec.at>)
List pgsql-hackers
Boszormenyi Zoltan <zb@cybertec.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, ieenable_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



pgsql-hackers by date:

Previous
From: Boszormenyi Zoltan
Date:
Subject: Re: Strange Windows problem, lock_timeout test request
Next
From: Boszormenyi Zoltan
Date:
Subject: Re: Strange Windows problem, lock_timeout test request