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-13T16:03:00Z
Lists: 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


gitpod=# set statement_timeout to '20ms'; set transaction_timeout to 0; --
to test value for statement_timeout and see that it doesn't fail
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


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)

[...]

                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)

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)

– it seems we could (should) have one more successful "1s wait, 3s sleep"
iteration here, ~727ms somehow wasted in a loop, quite a lot.

Commits

  1. Add TAP tests for timeouts

  2. Remove flaky isolation tests for timeouts

  3. Followup fixes for transaction_timeout

  4. Introduce transaction_timeout

  5. On systems that have setsid(2) (which should be just about everything except