|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
[2003-10-14 13:52 UTC] chris at statgen dot ncsu dot edu
[2003-10-14 14:00 UTC] lsmith@php.net
|
|||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Sat Oct 25 08:00:01 2025 UTC |
Description: ------------ Issues with freeing Prepared Queries ------------------------------------ Here are some issues with freeing prepared queries in the PostgreSQL implementation of DB. 1) If you use the query member in the form where you provide parameter values as a second argument the query is prepared and executed but the values produced by the prepare step are never freed. This leads to a considerable memory leaks if the query member is used repeatedly in a long-running process. Here's a suggested fix for this one. In DB_common::query, changes marked with "CSCS": function &query($query, $params = array()) { if (sizeof($params) > 0) { $sth = $this->prepare($query); if (DB::isError($sth)) { return $sth; } // CSCS Prepared query should be freed // CSCS return $this->execute($sth, $params); $res = &$this->execute($sth, $params); // CSCS $this->freeResult($sth); // CSCS return $res; // CSCS } else { 2) If you explicitly prepare a query there is no documented method defined for freeing the prepared version. This is (generally) a smaller memory leak since queries are usually prepared once and re-used often. 3) The freeResult member of DB_pgsql does not unset the query's entry in the prepared_queries array. The entries in the prepare_tokens and prepare_types arrays are freed. Suggested fix in DB_pgsql::freeResult is to add one line... unset($this->prepare_tokens[(int)$result]); unset($this->prepare_types[(int)$result]); unset($this->prepared_queries[(int)$result]); // CSCS 4) Not sure what effect this has but the prepare_tokens and prepare_types arrays are defined in both the base DB_common class and the DB_pgsql class. It seems like just having them in the DB_common class would be enough. Reproduce code: --------------- Let me know if you would like some reproduce code.