| From: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
|---|---|
| To: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | anole's failed timeouts test |
| Date: | 2019-02-11 03:50:43 |
| Message-ID: | CAEepm=3j+-REWamecBWgRR4xSxfQ2d0XtYGehAVqTNeT6-wnBQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Justin Pryzby | 2019-02-11 04:01:32 | Re: pg11.1: dsa_area could not attach to segment |
| Previous Message | PG Bug reporting form | 2019-02-11 03:26:13 | BUG #15629: Typo in Documentation |