From: | Tatsuo Ishii <ishii(at)postgresql(dot)org> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Statement timeout |
Date: | 2016-05-28 13:04:42 |
Message-ID: | 20160528.220442.1489791680347556026.t-ishii@sraoss.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
When extended query protocol message is used, statement timeout is not
checked until a sync message is received (more precisely, statement
timeout timer is canceled while processing the sync message, and
actual checking timeout is done in CHECK_FOR_INTERRUPTS). Example:
parse(statement1)
bind(statement1, portal1)
execute(portal1)
parse(statement2)
bind(statement2, portal2)
execute(portal2)
sync
Suppose statement_timeout = 2s. If execute(portal1) takes 3 seconds,
and execute(portal2) takes 1 second, the statement timeout is reported
at the time when the sync message is processed which is right after
execute(portal2). This may lead to certain confusions to users:
1) If log_min_error_statement is ERROR or below, the cause of statement
timeout is reported as statement2, rather than statement1.
2) If log_duration is set, the execution time for execute(portal1) is
3 seconds, and execute(portal2) is 1 second which looks
inconsistent with #1.
3) If the sync message arrives long time after execute(portal2) (say,
3 seconds), statement timeout will raised even if execute(portal1)
and execute(portal2) take less than 2 seconds.
Is there any room to enhance this? For example calling
disable_timeout(STATEMENT_TIMEOUT, false) in exec_execute_message.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
From | Date | Subject | |
---|---|---|---|
Next Message | Kouhei Kaigai | 2016-05-28 14:12:24 | Re: Does people favor to have matrix data type? |
Previous Message | Amit Kapila | 2016-05-28 03:29:36 | Re: Parallel pg_dump's error reporting doesn't work worth squat |