Parameter setting in multi-statement command; I got bit today

From: Jerry Sievers <gsievers19(at)comcast(dot)net>
To: pgsql-general(at)postgresql(dot)org
Subject: Parameter setting in multi-statement command; I got bit today
Date: 2012-04-01 19:02:56
Message-ID: 87hax3e0m7.fsf@comcast.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Just FYI... maybe I'm the only Pg veteran who didn't know this but;

Parameter settings in a multi-statement command are not in effect for
later statements in same command. They will take effect on later
commands however as seen below.

The 2 seconds statement timeout does nothing to prevent the sleep(10)
from completing.

Platform was Python 2.6 and EDB 8.2. In the real world, we discovered
this because, I was using such an approach to set a 15 second timeout
so that the next statement, an exclusive lock request would abort is
couldn't be obtained after 15 secs.

This was to avoid contention in situation where a long-running report
was holding a lock.

This behavior is quite likely documented somewhere but if so, not
apparent to me.

Silly example follows...

$ python
Python 2.6.6 (r266:84292, Sep 15 2010, 16:22:56)
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>import pgdb
>conn = pgdb.connect()
>cur = conn.cursor()
>cur.execute("set statement_timeout to '2s'; select pg_sleep(10)")
# first invocation of this succeeds due to the 2s timeout not being
effective yet.

>cur.execute("select pg_sleep(10)")
# A 2s delay here and then exception

Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python2.6/dist-packages/pgdb.py", line 259, in execute
self.executemany(operation, (params,))
File "/usr/lib/python2.6/dist-packages/pgdb.py", line 289, in executemany
raise DatabaseError("error '%s' in '%s'" % (msg, sql))
pg.DatabaseError: error 'ERROR: canceling statement due to statement timeout
' in 'set statement_timeout to '2s'; select pg_sleep(10)'

It is tedious and I guess mostly unnecessary to do cur.execute("foo")
for each statement and as such, a clever guy might adopt the habit
of piling all sorts of code into a single execute().

Along these lines, I'd be curious to know of other good reasong for
*not* combining statements like this.

Thanks>

--
Jerry Sievers
Postgres DBA/Development Consulting
e: postgres(dot)consulting(at)comcast(dot)net
p: 732.216.7255

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Adrian Klaver 2012-04-01 19:13:23 Re: Trigger.. AFTER and BEFORE with specific column changed
Previous Message Albert 2012-04-01 18:45:39 Trigger.. AFTER and BEFORE with specific column changed