> Really? It should get reported at some execution of CHECK_FOR_INTERRUPTS > after we pass the 2-second mark in execute(portal1). If that's not what > you're observing, maybe you've found a code path that's missing some > CHECK_FOR_INTERRUPTS call(s).
Oops. Previous example was not appropriate. Here are revised examples. (in any case, the time consumed at parse and bind are small, and I omit the CHECK_FOR_INTERRUPTS after these commands) [example 1] statement_timeout = 3s parse(statement1) -- time 0. set statement timout timer bind(statement1, portal1) execute(portal1) -- took 2 seconds CHECK_FOR_INTERRUPTS -- 2 seconds passed since time 0. statement timeout does not fire parse(statement2) bind(statement2, portal2) execute(portal2) -- took 2 seconds CHECK_FOR_INTERRUPTS -- 4 seconds passed since time 0. the statement timeout fires! Another example. [example 2] statement_timeout = 3s parse(statement1) -- time 0. set statement timout timer bind(statement1, portal1) execute(portal1) -- took 1 second CHECK_FOR_INTERRUPTS -- 1 second passed since time 0. statement timeout does not fire parse(statement2) bind(statement2, portal2) execute(portal2) -- took 1 second CHECK_FOR_INTERRUPTS -- 2 seconds passed since time 0. the statement timeout fires! [client is idle for 2 seconds] sync CHECK_FOR_INTERRUPTS -- 4 seconds passed since time 0. the statement timeout fires! I think current code is good in detecting statement timeout if each command execution time actually exceeds the specified timeout. However it could report false statement timeout in some cases like above. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers