Skip site navigation (1) Skip section navigation (2)

Re: Statement Timeout and Locking

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Kris Jurka <books(at)ejurka(dot)com>
Cc: Markus Schaber <schabi(at)logix-tt(dot)com>,"pgsql-jdbc(at)postgresql(dot)org" <pgsql-jdbc(at)postgresql(dot)org>,pgsql-hackers(at)postgresql(dot)org
Subject: Re: Statement Timeout and Locking
Date: 2005-04-28 15:59:41
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-jdbc
Kris Jurka <books(at)ejurka(dot)com> 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

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

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,

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Andreas PflugDate: 2005-04-28 16:36:03
Subject: Re: Feature freeze date for 8.1
Previous:From: Magnus HaganderDate: 2005-04-28 15:38:55
Subject: Re: [HACKERS] Increased company involvement

pgsql-jdbc by date

Next:From: Markus SchaberDate: 2005-04-28 17:35:34
Subject: Re: Statement Timeout and Locking
Previous:From: Kris JurkaDate: 2005-04-28 15:22:01
Subject: Re: Statement Timeout and Locking

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group