anole's failed timeouts test

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: Raw Message | Whole Thread | 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

Responses

Browse pgsql-hackers by date

  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