Re: [PATCH] lock_timeout and common SIGALRM framework

2012-04-04 17:12 keltezéssel, Boszormenyi Zoltan írta:
> 2012-04-04 16:22 keltezéssel, Boszormenyi Zoltan írta:
>> 2012-04-04 15:17 keltezéssel, Boszormenyi Zoltan írta:
>>> Hi,
>>>
>>> 2012-04-04 12:30 keltezéssel, Boszormenyi Zoltan írta:
>>>> Hi,
>>>>
>>>> attached is a patch to implement a framework to simplify and
>>>> correctly nest multiplexing more than two timeout sources
>>>> into the same SIGALRM signal handler.
>>>>
>>>> The framework is using a new internal API for timeouts:
>>>>
>>>> bool enable_timeout(TimeoutName tn, int delayms);
>>>> bool disable_timeout(TimeoutName tn, bool keep_indicator);
>>>> bool disable_all_timeouts(bool keep_indicators);
>>>>
>>>> A timeout source has these features to allow different initialization,
>>>> cleanup and check functions and rescheduling:
>>>>
>>>> typedef void (*timeout_init)(TimestampTz, TimestampTz);
>>>> typedef void (*timeout_destroy)(bool);
>>>> typedef bool (*timeout_check)(void);
>>>> typedef TimestampTz (*timeout_start)(void);
>>>>
>>>> typedef struct {
>>>> TimeoutName index;
>>>> bool resched_next;
>>>> timeout_init timeout_init;
>>>> timeout_destroy timeout_destroy;
>>>> timeout_check timeout_check;
>>>> timeout_start timeout_start;
>>>> TimestampTz fin_time;
>>>> } timeout_params;
>>>>
>>>> This makes it possible to differentiate between the standby and
>>>> statement timeouts, regular deadlock and standby deadlock using
>>>> the same signal handler function.
>>>>
>>>> And finally, this makes it possible to implement the lock_timeout
>>>> feature that we at Cybertec implemented more than 2 years ago.
>>>>
>>>> The patch also adds two new tests into prepared_xacts.sql to trigger
>>>> the lock_timeout instead of statement_timeout.
>>>>
>>>> Documentation and extensive comments are included.
>>>
>>> Second version. Every timeout-related functions are now in a separate
>>> source file, src/backend/storage/timeout.c with accessor functions.
>>> There are no related global variables anymore, only the GUCs.
>>
>> 3rd and (for now) final version.
>
> I lied. This is the final one. I fixed a typo in the documentation
> and replaced timeout_start_time (previously static to proc.c)
> with get_timeout_start(DEADLOCK_TIMEOUT). This one should
> have happened in the second version.
>
>> Tidied comments, the time checks in
>> Check*() functions and function order in timeout.c.
>>
>>>
>>>>
>>>> Best regards,
>>>> Zoltán Böszörményi

One comment for testers: all the timeout GUC values are given in
milliseconds, the kernel interface (setitimer) and TimestampTz uses
microseconds.

The transaction that locks is inherently a read/write one and by the time
the code reaches ProcSleep(), at least a few tens of microseconds has
already passed since the start of the statement even on 3GHz+ CPUs.

Not to mention that computers nowadays have high precision timers
and OSs running on them utilitize those. So, the time returned by
GetCurrentStatementStartTimestamp() will certainly be different from
GetCurrentTimestamp(). This means that the timeouts' fin_time will also
be different.

Long story short, using the same value for statement_timeout and
lock_timeout (or deadlock_timeout for that matter) means that
statement_timeout will trigger first. The story is different only on
a combination of a fast CPU and an OS with greater-then-millisecond
timer resolution.

Best regards,
Zoltán Böszörményi

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