]> granicus.if.org Git - postgresql/commit
Revert my bad decision of about a year ago to make PortalDefineQuery
authorTom Lane <tgl@sss.pgh.pa.us>
Wed, 2 Apr 2008 18:31:50 +0000 (18:31 +0000)
committerTom Lane <tgl@sss.pgh.pa.us>
Wed, 2 Apr 2008 18:31:50 +0000 (18:31 +0000)
commit1591fcbec77f6544a0f665758bae912c68e6fa42
tree164febe5a5dac789fc6194235312c15c3ce4e1fe
parentad6bf716baa7c4c1d0c2fbece0344046e3ce1173
Revert my bad decision of about a year ago to make PortalDefineQuery
responsible for copying the query string into the new Portal.  Such copying
is unnecessary in the common code path through exec_simple_query, and in
this case it can be enormously expensive because the string might contain
a large number of individual commands; we were copying the entire, long
string for each command, resulting in O(N^2) behavior for N commands.
(This is the cause of bug #4079.)  A second problem with it is that
PortalDefineQuery really can't risk error, because if it elog's before
having set up the Portal, we will leak the plancache refcount that the
caller is trying to hand off to the portal.  So go back to the design in
which the caller is responsible for making sure everything is copied into
the portal if necessary.
src/backend/commands/portalcmds.c
src/backend/commands/prepare.c
src/backend/executor/spi.c
src/backend/tcop/postgres.c
src/backend/utils/mmgr/portalmem.c