On 2017-04-05 00:39:51 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2017-04-05 10:05:19 +0900, Tatsuo Ishii wrote:
> >> What's your point of the question? What kind of problem do you expect
> >> if the timeout starts only once at the first parse meesage out of
> >> bunch of parse messages?
>
> > It's perfectly valid to send a lot of Parse messages without
> > interspersed Sync or Bind/Execute message. There'll be one timeout
> > covering all of those Parse messages, which can thus lead to a timeout,
> > even though nothing actually takes long individually.
>
> It might well be reasonable to redefine statement_timeout as limiting the
> total time from the first client input to the response to Sync ...
That's actually the current behaviour. start_xact_command arms the timer
in the !xact_started case, and only finish_xact_command() disarms it.
finish_xact_command() is issued for Sync messsages and simple statements.
I brought the case up because what we're discussing is changing things
so Execute resets the clock (more precisely disables it, and have it
reenabled later). So it'd be "fixed" for pipelined Execute statements,
but not for pipelined Parses. Changing things so that Parse/Bind also
reset the timing would increase overhead - and it'd not be useful in
practice, because Sync's are sent by the drivers that support
pipelining when statements are prepared.
> but
> if that's what we're doing, let's make sure we do it consistently.
> I haven't read the patch, but the comments in this thread make me fear
> that it's introducing some ad-hoc, inconsistent behavior.
I'm a bit worried too due to the time constraints here, but I think
resetting the clock at Execute too actually makes a fair amount sense.
Greetings,
Andres Freund
