Обсуждение: anole's failed timeouts test

Hello,

 step lsto: SET lock_timeout = 5000; SET statement_timeout = 6000;
 step update: DELETE FROM accounts WHERE accountid = 'checking'; <waiting ...>
 step update: <... completed>
-ERROR:  canceling statement due to lock timeout
+ERROR:  canceling statement due to statement timeout

No matter how slow the machine is, how can you manage to get statement
timeout to fire first?  Given the coding that prefers lock timeouts if
there is a tie (unlikely), but otherwise processes them in registered
time order (assuming the clock only travels forward), well, I must be
missing something...

-- 
Thomas Munro
http://www.enterprisedb.com

Thomas Munro <thomas.munro@enterprisedb.com> writes:
> Hello,
>  step lsto: SET lock_timeout = 5000; SET statement_timeout = 6000;
>  step update: DELETE FROM accounts WHERE accountid = 'checking'; <waiting ...>
>  step update: <... completed>
> -ERROR:  canceling statement due to lock timeout
> +ERROR:  canceling statement due to statement timeout

> No matter how slow the machine is, how can you manage to get statement
> timeout to fire first?

The statement timer starts running first; the lock timer only starts
to run when we begin to wait for a lock.  So if the session goes to
sleep for > 1 second in between those events, this is unsurprising.

There are a bunch of tests in timeouts.spec that are unreasonably
slow because the timeouts have been whacked until even very slow/
overloaded machines will pass the tests.  Maybe we need to tweak
this one too.

            regards, tom lane