Re: Transaction timeout
От | Nikolay Samokhvalov |
---|---|
Тема | Re: Transaction timeout |
Дата | |
Msg-id | CANNMO+K01WNSddTOVF6hAo1VGA4K0mFd7RFBBjzSUYNqCGRt_g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Transaction timeout (Andrey Borodin <amborodin86@gmail.com>) |
Ответы |
Re: Transaction timeout
(Andrey Borodin <amborodin86@gmail.com>)
|
Список | pgsql-hackers |
On Thu, Jan 12, 2023 at 11:47 AM Andrey Borodin <amborodin86@gmail.com> wrote:
On Thu, Jan 12, 2023 at 11:24 AM Nathan Bossart
<nathandbossart@gmail.com> wrote:
>
> On Sun, Dec 18, 2022 at 12:53:31PM -0800, Andrey Borodin wrote:
> > I've rewritten this part to correctly report all timeouts that did
> > happen. However there's now a tricky comma-formatting code which was
> > tested only manually.
Testing it again, a couple of questions
1) The current test set has only 2 simple cases – I'd suggest adding one more (that one that didn't work in v1):
gitpod=# set transaction_timeout to '20ms';
SET
gitpod=# begin; select pg_sleep(.01); select pg_sleep(.01); select pg_sleep(.01); commit;
BEGIN
pg_sleep
----------
(1 row)
ERROR: canceling statement due to transaction timeout
SET
gitpod=# begin; select pg_sleep(.01); select pg_sleep(.01); select pg_sleep(.01); commit;
BEGIN
pg_sleep
----------
(1 row)
ERROR: canceling statement due to transaction timeout
SET
SET
gitpod=# begin; select pg_sleep(.01); select pg_sleep(.01); select pg_sleep(.01); commit;
BEGIN
pg_sleep
----------
(1 row)
pg_sleep
----------
(1 row)
pg_sleep
----------
(1 row)
COMMIT
gitpod=# begin; select pg_sleep(.01); select pg_sleep(.01); select pg_sleep(.01); commit;
BEGIN
pg_sleep
----------
(1 row)
pg_sleep
----------
(1 row)
pg_sleep
----------
(1 row)
COMMIT
2) Testing for a longer transaction (2 min), in a gitpod VM (everything is local, no network involved)
// not sure what's happening here, maybe some overheads that are not related to the implementation,
// but the goal was to see how precise the limiting is for longer transactions
gitpod=# set transaction_timeout to '2min';
SET
gitpod=# begin;
BEGIN
gitpod=*# select now(), clock_timestamp(), pg_sleep(3) \watch 1
Fri 13 Jan 2023 03:49:24 PM UTC (every 1s)
now | clock_timestamp | pg_sleep
-------------------------------+-------------------------------+----------
2023-01-13 15:49:22.906924+00 | 2023-01-13 15:49:24.088728+00 |
(1 row)
SET
gitpod=# begin;
BEGIN
gitpod=*# select now(), clock_timestamp(), pg_sleep(3) \watch 1
Fri 13 Jan 2023 03:49:24 PM UTC (every 1s)
now | clock_timestamp | pg_sleep
-------------------------------+-------------------------------+----------
2023-01-13 15:49:22.906924+00 | 2023-01-13 15:49:24.088728+00 |
(1 row)
[...]
Fri 13 Jan 2023 03:51:18 PM UTC (every 1s)
now | clock_timestamp | pg_sleep
-------------------------------+-------------------------------+----------
2023-01-13 15:49:22.906924+00 | 2023-01-13 15:51:18.179579+00 |
(1 row)
ERROR: canceling statement due to transaction timeout
gitpod=!#
gitpod=!# rollback;
ROLLBACK
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)
now | clock_timestamp | pg_sleep
-------------------------------+-------------------------------+----------
2023-01-13 15:49:22.906924+00 | 2023-01-13 15:51:18.179579+00 |
(1 row)
ERROR: canceling statement due to transaction timeout
gitpod=!#
gitpod=!# rollback;
ROLLBACK
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)
gitpod=# select interval '2min' - '00:01:55.272655';
?column?
-----------------
00:00:04.727345
(1 row)
gitpod=# select interval '2min' - '00:01:55.272655' - '4s';
?column?
-----------------
00:00:00.727345
(1 row)
?column?
-----------------
00:00:04.727345
(1 row)
gitpod=# select interval '2min' - '00:01:55.272655' - '4s';
?column?
-----------------
00:00:00.727345
(1 row)
– it seems we could (should) have one more successful "1s wait, 3s sleep" iteration here, ~727ms somehow wasted in a loop, quite a lot.
В списке pgsql-hackers по дате отправления: