Fix auto-prepare #2 - Mailing list pgsql-hackers

From Boszormenyi Zoltan
Subject Fix auto-prepare #2
Date
Msg-id 4B543EDE.4080105@cybertec.at
Whole thread Raw
In response to Re: ECPG patch N+1, fix auto-prepare  (Michael Meskes <meskes@postgresql.org>)
Responses Re: Fix auto-prepare #2  (Takahiro Itagaki <itagaki.takahiro@oss.ntt.co.jp>)
List 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

pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: Streaming Replication on win32
Next
From: Fujii Masao
Date:
Subject: Re: Hot Standby and handling max_standby_delay