public inbox for [email protected]
help / color / mirror / Atom feedFrom: Japin Li <[email protected]>
To: Junwang Zhao <[email protected]>
Cc: Andrey M. Borodin <[email protected]>
Cc: 邱宇航 <[email protected]>
Cc: Fujii Masao <[email protected]>
Cc: Andrey Borodin <[email protected]>
Cc: Andres Freund <[email protected]>
Cc: Michael Paquier <[email protected]>
Cc: Nikolay Samokhvalov <[email protected]>
Cc: pgsql-hackers <[email protected]>
Cc: [email protected]
Subject: Re: Transaction timeout
Date: Fri, 22 Dec 2023 22:25:37 +0800
Message-ID: <ME3P282MB316662CE6ED67FB49C930BC9B694A@ME3P282MB3166.AUSP282.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <CAEG8a3J4DY1VaSd-GHkN8VHXV0vGkO83-Y50OUyac+jObmFW+g@mail.gmail.com>
References: <CAAhFRxiQsRs2Eq5kCo9nXE3HTugsAAJdSQSmxncivebAxdmBjQ@mail.gmail.com>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<SY8PR01MB9288C3D90276EB758E066694B68BA@SY8PR01MB9288.ausprd01.prod.outlook.com>
<[email protected]>
<SY8PR01MB9288F5CF03D38662BE59C628B68AA@SY8PR01MB9288.ausprd01.prod.outlook.com>
<[email protected]>
<SY8PR01MB9288335A3B81E8D6E121980FB68AA@SY8PR01MB9288.ausprd01.prod.outlook.com>
<[email protected]>
<ME3P282MB3166E33F193D2E7B0CDB633FB692A@ME3P282MB3166.AUSP282.PROD.OUTLOOK.COM>
<[email protected]>
<MEYP282MB316457B6810B840A012649AFB690A@MEYP282MB3164.AUSP282.PROD.OUTLOOK.COM>
<[email protected]>
<ME3P282MB316699E4C3A165983731076EB697A@ME3P282MB3166.AUSP282.PROD.OUTLOOK.COM>
<[email protected]>
<[email protected]>
<ME3P282MB316662848DEF947EE0B4B091B697A@ME3P282MB3166.AUSP282.PROD.OUTLOOK.COM>
<ME3P282MB3166FCD27CCC06C8E94134B5B694A@ME3P282MB3166.AUSP282.PROD.OUTLOOK.COM>
<CAEG8a3J4DY1VaSd-GHkN8VHXV0vGkO83-Y50OUyac+jObmFW+g@mail.gmail.com>
On Fri, 22 Dec 2023 at 20:29, Junwang Zhao <[email protected]> wrote:
> On Fri, Dec 22, 2023 at 1:39 PM Japin Li <[email protected]> wrote:
>>
>>
>> On Tue, 19 Dec 2023 at 22:06, Japin Li <[email protected]> wrote:
>> > On Tue, 19 Dec 2023 at 18:27, Andrey M. Borodin <[email protected]> wrote:
>> >>> On 19 Dec 2023, at 13:26, Andrey M. Borodin <[email protected]> wrote:
>> >>>
>> >>> I don’t have Windows machine, so I hope CF bot will pick this.
>> >>
>> >> I used Github CI to produce version of tests that seems to be is stable on Windows.
>> >
>> > It still failed on Windows Server 2019 [1].
>> >
>> > diff -w -U3 C:/cirrus/src/test/isolation/expected/timeouts.out C:/cirrus/build/testrun/isolation/isolation/results/timeouts.out
>> > --- C:/cirrus/src/test/isolation/expected/timeouts.out 2023-12-19 10:34:30.354721100 +0000
>> > +++ C:/cirrus/build/testrun/isolation/isolation/results/timeouts.out 2023-12-19 10:38:25.877981600 +0000
>> > @@ -100,7 +100,7 @@
>> > step stt3_check_stt2: SELECT count(*) FROM pg_stat_activity WHERE application_name = 'isolation/timeouts/stt2'
>> > count
>> > -----
>> > - 0
>> > + 1
>> > (1 row)
>> >
>> > step itt4_set: SET idle_in_transaction_session_timeout = '1ms'; SET statement_timeout = '10s'; SET lock_timeout = '10s'; SET transaction_timeout = '10s';
>> >
>> > [1] https://api.cirrus-ci.com/v1/artifact/task/4707530400595968/testrun/build/testrun/isolation/isolatio...
>>
>> Hi,
>>
>> I try to split the test for transaction timeout, and all passed on my CI [1].
>>
>> OTOH, I find if I set transaction_timeout in a transaction, it will not take
>> effect immediately. For example:
>>
>> [local]:2049802 postgres=# BEGIN;
>> BEGIN
>> [local]:2049802 postgres=*# SET transaction_timeout TO '1s';
> when this execute, TransactionTimeout is still 0, this command will
> not set timeout
>> SET
>> [local]:2049802 postgres=*# SELECT relname FROM pg_class LIMIT 1; -- wait 10s
> when this command get execute, start_xact_command will enable the timer
Thanks for your exaplantion, got it.
>> relname
>> --------------
>> pg_statistic
>> (1 row)
>>
>> [local]:2049802 postgres=*# SELECT relname FROM pg_class LIMIT 1;
>> FATAL: terminating connection due to transaction timeout
>> server closed the connection unexpectedly
>> This probably means the server terminated abnormally
>> before or while processing the request.
>> The connection to the server was lost. Attempting reset: Succeeded.
>>
>> It looks odd. Does this is expected? I'm not read all the threads,
>> am I missing something?
>
> I think this is by design, if you debug statement_timeout, it's the same
> behaviour, the timeout will be set for each command after the second
> command was called, you just aren't aware of this.
>
I try to set idle_in_transaction_session_timeout after begin transaction,
it changes immediately, so I think transaction_timeout should also be take
immediately.
> I doubt people will set this in a transaction.
Maybe not,
--
Regrads,
Japin Li
ChengDu WenWu Information Technology Co., Ltd.
view thread (61+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Transaction timeout
In-Reply-To: <ME3P282MB316662CE6ED67FB49C930BC9B694A@ME3P282MB3166.AUSP282.PROD.OUTLOOK.COM>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox