From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
---|---|
To: | andres(at)anarazel(dot)de |
Cc: | amborodin86(at)gmail(dot)com, samokhvalov(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Transaction timeout |
Date: | 2022-12-07 02:52:39 |
Message-ID: | 20221207.115239.2227711014442673928.horikyota.ntt@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
At Mon, 5 Dec 2022 17:10:50 -0800, Andres Freund <andres(at)anarazel(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | vignesh C | 2022-12-07 02:55:25 | Re: Commit fest 2022-11 |
Previous Message | Amit Kapila | 2022-12-07 02:44:32 | Re: Force streaming every change in logical decoding |