Re: Transaction timeout
Kyotaro Horiguchi <horikyota.ntt@gmail.com>
From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
To: andres@anarazel.de
Cc: amborodin86@gmail.com, samokhvalov@gmail.com,
pgsql-hackers@postgresql.org
Date: 2022-12-07T02:52:39Z
Lists: pgsql-hackers
At Mon, 5 Dec 2022 17:10:50 -0800, Andres Freund <andres@anarazel.de> wrote in > I'm most concerned about the overhead when the timeouts are *not* > enabled. And this adds a branch to start_xact_command() and a function > call for get_timeout_active(TRANSACTION_TIMEOUT) in that case. On its > own, that's not a whole lot, but it does add up. There's 10+ function > calls for timeout and ps_display purposes for every single statement. That path seems like existing just for robustness. I inserted "Assert(0)" just before the disable_timeout(), but make check-world didn't fail [1]. Couldn't we get rid of that path, adding an assertion instead? I'm not sure about other timeouts yet, though. About disabling side, we cannot rely on StatementTimeout. [1] # 032_apply_delay.pl fails for me so I don't know any of the later # tests fails. > But it's definitely also worth optimizing the timeout enabled paths. And > you're right, it looks like there's a fair bit of optimization > potential. Thanks. I'll work on that. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
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