| From: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> |
|---|---|
| To: | Andrey Borodin <amborodin86(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Nikolay Samokhvalov <samokhvalov(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Transaction timeout |
| Date: | 2023-09-06 08:16:16 |
| Message-ID: | a906dea1-76a1-4f26-76c5-a7efad3ef5b8@oss.nttdata.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2022/12/19 5:53, Andrey Borodin wrote:
> On Wed, Dec 7, 2022 at 1:30 PM Andrey Borodin <amborodin86(at)gmail(dot)com> wrote:
>> I hope to address other feedback on the weekend.
Thanks for implementing this feature!
While testing v4 patch, I noticed it doesn't handle the COMMIT AND CHAIN case correctly.
When COMMIT AND CHAIN is executed, I believe the transaction timeout counter should reset
and start from zero with the next transaction. However, it appears that the current
v4 patch doesn't reset the counter in this scenario. Can you confirm this?
With the v4 patch, I found that timeout errors no longer occur during the idle in
transaction phase. Instead, they occur when the next statement is executed. Is this
the intended behavior? I thought some users might want to use the transaction timeout
feature to prevent prolonged transactions and promptly release resources (e.g., locks)
in case of a timeout, similar to idle_in_transaction_session_timeout.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2023-09-06 08:19:14 | Re: [Regression] Incorrect filename in test case comment |
| Previous Message | Quan Zongliang | 2023-09-06 07:55:03 | Re: Improving the heapgetpage function improves performance in common scenarios |