Re: [PATCH] lock_timeout and common SIGALRM framework - Mailing list pgsql-hackers

2012-04-04 17:12 keltezéssel, Boszormenyi Zoltan írta: <blockquote cite="mid:4F7C64F2.5070905@cybertec.at"
type="cite">2012-04-04 16:22 keltezéssel, Boszormenyi Zoltan írta: <blockquote cite="mid:4F7C5925.107@cybertec.at"
type="cite">2012-04-04 15:17 keltezéssel, Boszormenyi Zoltan írta: <blockquote cite="mid:4F7C49DA.7080008@cybertec.at"
type="cite">Hi,<br /><br /> 2012-04-04 12:30 keltezéssel, Boszormenyi Zoltan írta: <br /><blockquote type="cite">Hi,
<br/><br /> attached is a patch to implement a framework to simplify and <br /> correctly nest multiplexing more than
twotimeout sources <br /> into the same SIGALRM signal handler. <br /><br /> The framework is using a new internal API
fortimeouts: <br /><br /> bool enable_timeout(TimeoutName tn, int delayms); <br /> bool disable_timeout(TimeoutName tn,
boolkeep_indicator); <br /> bool disable_all_timeouts(bool keep_indicators); <br /><br /> A timeout source has these
featuresto allow different initialization, <br /> cleanup and check functions and rescheduling: <br /><br /> typedef
void(*timeout_init)(TimestampTz, TimestampTz); <br /> typedef void (*timeout_destroy)(bool); <br /> typedef bool
(*timeout_check)(void);<br /> typedef TimestampTz (*timeout_start)(void); <br /><br /> typedef struct { <br />        
TimeoutName    index; <br />         bool            resched_next; <br />         timeout_init    timeout_init; <br />
       timeout_destroy timeout_destroy; <br />         timeout_check   timeout_check; <br />         timeout_start  
timeout_start;<br />         TimestampTz     fin_time; <br /> } timeout_params; <br /><br /> This makes it possible to
differentiatebetween the standby and <br /> statement timeouts, regular deadlock and standby deadlock using <br /> the
samesignal handler function. <br /><br /> And finally, this makes it possible to implement the lock_timeout <br />
featurethat we at Cybertec implemented more than 2 years ago. <br /><br /> The patch also adds two new tests into
prepared_xacts.sqlto trigger <br /> the lock_timeout instead of statement_timeout. <br /><br /> Documentation and
extensivecomments are included. <br /></blockquote><br /> Second version. Every timeout-related functions are now in a
separate<br /> source file, src/backend/storage/timeout.c with accessor functions. <br /> There are no related global
variablesanymore, only the GUCs. <br /></blockquote><br /> 3rd and (for now) final version.</blockquote><br /> I lied.
Thisis the final one. I fixed a typo in the documentation<br /> and replaced timeout_start_time (previously static to
proc.c)<br/> with get_timeout_start(DEADLOCK_TIMEOUT). This one should<br /> have happened in the second version.<br
/><br/><blockquote cite="mid:4F7C5925.107@cybertec.at" type="cite"> Tidied comments, the time checks in<br /> Check*()
functionsand function order in timeout.c.<br /><br /><blockquote cite="mid:4F7C49DA.7080008@cybertec.at"
type="cite"><br/><blockquote type="cite"><br /> Best regards, <br /> Zoltán Böszörményi <br
/></blockquote></blockquote></blockquote></blockquote><br/> One comment for testers: all the timeout GUC values are
givenin<br /> milliseconds, the kernel interface (setitimer) and TimestampTz uses<br /> microseconds.<br /><br /> The
transactionthat locks is inherently a read/write one and by the time<br /> the code reaches ProcSleep(), at least a few
tensof microseconds has<br /> already passed since the start of the statement even on 3GHz+ CPUs.<br /><br /> Not to
mentionthat computers nowadays have high precision timers<br /> and OSs running on them utilitize those. So, the time
returnedby<br /> GetCurrentStatementStartTimestamp() will certainly be different from<br /> GetCurrentTimestamp(). This
meansthat the timeouts' fin_time will also<br /> be different.<br /><br /> Long story short, using the same value for
statement_timeoutand<br /> lock_timeout (or deadlock_timeout for that matter) means that<br /> statement_timeout will
triggerfirst. The story is different only on<br /> a combination of a fast CPU and an OS with
greater-then-millisecond<br/> timer resolution.<br /><br /> Best regards,<br /> Zoltán Böszörményi<br /><br /><pre
class="moz-signature"cols="90">--  
----------------------------------
Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt, Austria
Web: <a class="moz-txt-link-freetext" href="http://www.postgresql-support.de">http://www.postgresql-support.de</a>
<aclass="moz-txt-link-freetext" href="http://www.postgresql.at/">http://www.postgresql.at/</a> 
</pre>