Re: Mail an JDBC driver
От | Tom Lane |
---|---|
Тема | Re: Mail an JDBC driver |
Дата | |
Msg-id | 25254.1470147778@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Mail an JDBC driver (Dave Cramer <pg@fastcrypt.com>) |
Список | pgsql-jdbc |
Dave Cramer <pg@fastcrypt.com> writes: > So I just tried using prepared statements and wasn't able to duplicate > this. It would be really nice if you could test this against at recent > version of PostgreSQL, and provide us with a self contained test case? I think that this is probably affected by this 9.3-era backend change: Author: Tom Lane <tgl@sss.pgh.pa.us> Branch: master Release: REL9_3_BR [0d5fbdc15] 2013-01-25 14:14:41 -0500 Change plan caching to honor, not resist, changes in search_path. In the initial implementation of plan caching, we saved the active search_path when a plan was first cached, then reinstalled that path anytime we needed to reparse or replan. The idea of that was to try to reselect the same referenced objects, in somewhat the same way that views continue to refer to the same objects in the face of schema or name changes. Of course, that analogy doesn't bear close inspection, since holding the search_path fixed doesn't cope with object drops or renames. Moreover sticking with the old path seems to create more surprises than it avoids. So instead of doing that, consider that the cached plan depends on search_path, and force reparse/replan if the active search_path is different than it was when we last saved the plan. This gets us fairly close to having "transparency" of plan caching, in the sense that the cached statement acts the same as if you'd just resubmitted the original query text for another execution. There are still some corner cases where this fails though: a new object added in the search path schema(s) might capture a reference in the query text, but we'd not realize that and force a reparse. We might try to fix that in the future, but for the moment it looks too expensive and complicated. With the 9.2 database, if you cache a DELETE query as a prepared statement, then it will retain the original search path and continue to use that if the statement needs to be replanned. Moreover I'm pretty sure that its notion of "original search path" was defined in terms of schema OIDs not names, so that the table in the renamed schema would continue to be targeted. We got rid of that behavior precisely because it turned out to be more surprising than useful ... but 9.2 is operating as designed. The apparent dependency on JDBC version probably has to do with different driver choices about whether/when to prepare the DELETE statement. regards, tom lane
В списке pgsql-jdbc по дате отправления: