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

Fix auto-prepare #2

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 (view raw or flat)
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: 6-pg85-fix-auto-prepare-multiconn-2.patch
Description: text/x-patch (1.6 KB)

In response to

Responses

pgsql-hackers by date

Next:From: Fujii MasaoDate: 2010-01-18 11:18:03
Subject: Re: Hot Standby and handling max_standby_delay
Previous:From: Fujii MasaoDate: 2010-01-18 10:11:39
Subject: Re: Streaming Replication on win32

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