Joseph Shraibman <jks@selectacast.net> writes:
> My update looks like:
> UPDATE tablename SET intfield = 2 WHERE keyfield IN( ... )
> If I lowered the number of items in the IN() then I didn't get the
> error, but what that number is is a moving target.
I've applied the attached patch to prevent this problem in 7.3.*.
A better solution will appear in 7.4, but I don't want to stick it into
the stable branch with no beta testing ...
regards, tom lane
*** src/backend/access/index/indexam.c.orig Wed Jan 8 14:41:57 2003
--- src/backend/access/index/indexam.c Sun Mar 23 16:44:37 2003
***************
*** 415,421 ****
--- 415,426 ----
*
* Note that we hold the pin on the single tuple's buffer throughout
* the scan once we are in this state.
+ *
+ * XXX disabled for 7.3.3 because it results in intra-query buffer leak
+ * when a multi-index indexscan is done. Full fix seems too risky to
+ * backpatch.
*/
+ #ifdef NOT_USED
if (scan->keys_are_unique && scan->got_tuple)
{
if (ScanDirectionIsForward(direction))
***************
*** 433,438 ****
--- 438,444 ----
else
return NULL;
}
+ #endif
/* Release any previously held pin */
if (BufferIsValid(scan->xs_cbuf))