Re: Transaction timeout
Nikolay Samokhvalov <samokhvalov@gmail.com>
From: Nikolay Samokhvalov <samokhvalov@gmail.com>
To: Andrey Borodin <amborodin86@gmail.com>
Cc: Nathan Bossart <nathandbossart@gmail.com>,
Andres Freund <andres@anarazel.de>, Michael Paquier <michael.paquier@gmail.com>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2023-01-13T19:00:32Z
Lists: pgsql-hackers
On Fri, Jan 13, 2023 at 10:16 AM Andrey Borodin <amborodin86@gmail.com>
wrote:
> > – it seems we could (should) have one more successful "1s wait, 3s
> sleep" iteration here, ~727ms somehow wasted in a loop, quite a lot.
>
> I think big chunk from these 727ms were spent between "BEGIN" and
> "select now(), clock_timestamp(), pg_sleep(3) \watch 1".
>
Not really – there was indeed ~2s delay between BEGIN and the first
pg_sleep query, but those ~727ms is something else.
here we measure the remainder between the beginning of the transaction
measured by "now()' and the the beginning of the last successful pg_sleep()
query:
gitpod=# select timestamptz '2023-01-13 15:51:18.179579+00' - '2023-01-13
15:49:22.906924+00';
?column?
-----------------
00:01:55.272655
(1 row)
It already includes all delays that we had from the beginning of our
transaction.
The problem with my question was that I didn't take into attention that
'2023-01-13 15:51:18.179579+00' is when the last successful query
*started*. So the remainder of our 2-min quota – 00:00:04.727345 – includes
the last successful loop (3s of successful query + 1s of waiting), and then
we have failed after ~700ms.
In other words, there are no issues here, all good.
> Many thanks for looking into this!
many thanks for implementing it
Commits
-
Add TAP tests for timeouts
- eeefd4280f6e 17.0 landed
-
Remove flaky isolation tests for timeouts
- a661bf7b0f56 17.0 landed
-
Followup fixes for transaction_timeout
- bf82f43790a6 17.0 landed
-
Introduce transaction_timeout
- 51efe38cb92f 17.0 landed
-
On systems that have setsid(2) (which should be just about everything except
- 3ad0728c817b 8.2.0 cited