From: | Boszormenyi Zoltan <zb(at)cybertec(dot)at> |
---|---|
To: | Michael Meskes <meskes(at)postgresql(dot)org> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Hans-Juergen Schoenig <hs(at)cybertec(dot)at> |
Subject: | Fix auto-prepare #2 |
Date: | 2010-01-18 10:58:38 |
Message-ID: | 4B543EDE.4080105@cybertec.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
we have found that auto-prepare causes a problem if the connection
is closed and re-opened and the previously prepared query is issued
again. The application gets back a error code -201 which seems bogus
and it turned out to be a missing
return (false);
after ecpg_raise(ECPG_SQLSTATE_INVALID_SQL_STATEMENT_NAME)
on line 1756 in execute.c, so the error handling later in the same function
masqueraded this error. But fixing this doesn't solve the main problem
that the query is in the auto-prepared query cache but not is not prepared
on the server if the connection is closed and re-opened.
The same problem may also arise if the same query is used over multiple
simultaneous connections.
This fix is that after looking up the query and having it found in the cache
we also have to check whether this query was prepared in the current
connection. The attached patch implements this fix and solves the problem
described above. Also, the missing "return false;" is also added to ECPGdo()
in execute.c.
Best regards,
Zoltán Böszörményi
--
Bible has answers for everything. Proof:
"But let your communication be, Yea, yea; Nay, nay: for whatsoever is more
than these cometh of evil." (Matthew 5:37) - basics of digital technology.
"May your kingdom come" - superficial description of plate tectonics
----------------------------------
Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH
http://www.postgresql.at/
Attachment | Content-Type | Size |
---|---|---|
6-pg85-fix-auto-prepare-multiconn-2.patch | text/x-patch | 1.6 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2010-01-18 11:18:03 | Re: Hot Standby and handling max_standby_delay |
Previous Message | Fujii Masao | 2010-01-18 10:11:39 | Re: Streaming Replication on win32 |