Kris Jurka [EMAIL PROTECTED] writes:
This actually is the problem. It works as three separate statements, but
fails as one. The server doesn't seem to recognize the SET when other
commands come in before Sync.
[ reads some code... ] The problem is that postgres.c only inspects
StatementTimeout when start_xact_command starts a transaction command,
and the placement of finish_xact_command calls is such that that's
not going to happen until after Sync. So the upshot is that the
SET statement_timeout isn't going to have effect until after Sync
(or after a transaction-control command, but there are none in your
example).
This suggests that the statement_timeout stuff is being done at the wrong
place. I'm not sure exactly what the more-right places would be for
V3 protocol though. What exactly would you expect statement_timeout to
cover in a Parse/Bind/Execute world --- especially if those aren't
issued in a purely sequential fashion?
A very simple definition would be that each Parse, Bind, or Execute
action is independently constrained by statement_timeout, but that would
act significantly differently from the simple-query case if planning
takes long enough to be a factor. (Bear in mind that planning can
include constant-folding of user-defined functions, so at least in some
cases you can imagine people would want statement_timeout to constrain
planning.) Also that would imply three times as many timer
enable/disable kernel calls, which might be an annoying amount of
overhead.
Anyway the short-term answer for Markus is don't do it that way.
We ought to think about making the backend's behavior more consistent,
though.
regards, tom lane
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
