Re: Fix auto-prepare #2
Takahiro Itagaki <itagaki.takahiro@oss.ntt.co.jp>
From: Takahiro Itagaki <itagaki.takahiro@oss.ntt.co.jp>
To: Boszormenyi Zoltan <zb@cybertec.at>
Cc: Michael Meskes <meskes@postgresql.org>, pgsql-hackers@postgresql.org, Hans-Juergen Schoenig <hs@cybertec.at>
Date: 2010-01-19T05:23:02Z
Lists: pgsql-hackers
Attachments
- 6-pg85-fix-auto-prepare-multiconn-3.patch (application/octet-stream) patch
- 6-pg85-fix-auto-prepare-multiconn-3-test.patch (application/octet-stream) patch
Hi, I'm reviewing your patch and have a couple of comments. Boszormenyi Zoltan <zb@cybertec.at> wrote: > 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. You didn't attach actual test cases for the bug, so I verified it by executing the routines twice in ecpg/test/preproc/autoprep.pgc. The attached "6-pg85-fix-auto-prepare-multiconn-3-test.patch" is an additional regression test for it. Is it enough for your case? > 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. In addition to the two issues, I found memory leaks by careless calls of ecpg_strdup() in ecpg_auto_prepare(). Prepared stetements also might leak in a error path. I tryd to fix both of them in the attached "6-pg85-fix-auto-prepare-multiconn-3.patch", but please recheck the issues. Regards, --- Takahiro Itagaki NTT Open Source Software Center