<p dir="ltr">Tatsuo,</p>
<p dir="ltr">Can you please review this so we can get this ready for checking in the master branch..</p>
<p dir="ltr">-- Ahsan<br>
</p>
<div class="gmail_quote">On 10 Feb 2014 19:53, "Muhammad Usama" <<a href="mailto:m.usama@gmail.com">m.usama@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Please find the penultimate patch for integration of memory and exception manager APIs into pgpool.<br>The patch is generated on the EXCEPTION_MGR development branch and integrates the said APIs in query processing portion of pgpool-II code.<br>
<br>Patch summary for review<br>======================<br>The patch is very large mainly because of replacing of pool_error(), pool_debug() and pool_log() function calls to ereport(ERROR,..) ereport(DEBUG,..) and ereport(LOG,..) and it would be little time consuming to review the patch. Although all the above also needs the thorough review, as replacing pool_error() with ereport(ERROR) or ereport(FATAL) is just not a cosmetic but changes the flow of code, but there are few things, that requires the more attention than others.<br>
<br>Lifecycle of objects.<br>================<br>Since with integration of memory manager, it is very important to manage the life cycle of each object and making sure the object is created in the proper MemoryContext. Here is the summary of some important objects and their residences.<br>
<br>Some Important Memory Contexts<br>============================<br><br>ProcessLoopContext: <div>This context resets at every main loop iteration of a process<div><br>TopMemoryContext:</div><div>This context is same as PostgreSQL's TopMemoryContext and lives for a life time of process.<br>
<br>ErrorContext:</div><div>Same as PostgreSQL's ErrorContext and used for error processing.<br><br>QueryContext:</div><div>Used by pgpool child process and it lives for single query cycle.<br><br><br>Lifecycle of Important Objects<br>
========================<br><br>SessionContext:<br>The session context consists of a backend and frontend connection and it lives for a single iteration of main child process loop.</div><div>So the session context object is created in ProcessLoopContext.<br>
<br>ProcessContext:<br>ConnectionPool:<br>BackendConnection:<br>The above objects are required for the life of process hence are created in TopMemoryContext which lives throughout the process life time.<br><br>Child Frontend connection:<br>
Frontend connection object is placed in the ProcessLoopContext since new frontend connection is created at every main loop iteration of pgpool child process.<br><br>PCP Frontend connection:</div><div>This object can live till the pcp process so the object for pcp frontend is created in TopMemoryContext.<br>
<br>new configuration parameters<br>========================<br><br>The patch also adds three new configuration parameters to control the error reporting style and details.</div><div>Parameters names and their behaviours are borrowed from PostgreSQL.<br>
<br>int log_error_verbosity; /* controls how much detail about error should be emitted */ <br><br>int client_min_messages; /*controls which message should be sent to client */<br> <br>int log_min_messages; /*controls which message should be emitted to server log */<br>
<br></div><div><br></div><div>Some other notable changes introduced by the patch.<br>==========================================</div><div><br>The patch changes the error reporting behaviour and now pgpool-II tries to send all the error and log messages to the connected frontend clients (controllable by "client_min_messages" configuration parameter ).<br>
<br>The patch added an extra call back "on_system_exit" to the elog API, which is not present in the PostgreSQL.</div><div>The call back is called at system exit by elog API just before calling the "on_shmem_exit" call backs.</div>
<div>"on_system_exit" is a single call back and can be used to clean up things which are dependent on shared memory.</div><div><br>"repalloc()" behaviour in PostgreSQL palloc API is little different from C-API counterpart "realloc()". </div>
<div>("realloc()" behaves as "malloc()" if ptr argument is NULL. While "repalloc()" does not works on NULL pointers)</div><div>So I have changed the behaviour of "repalloc()" to make it more consistent with C-API.<br>
<br>The patch makes the libpcp exclusive for the tool binaries only (compile with POOL_PRIVATE flag ). pgpool binary no longer has the dependancy on the lib, and uses the pcp_stream.c function directly. </div><div>For this new arrangement the patch also rearranges the source code organisation and moves the pcp_stream.c and pcp_error.c files to src/utils/pcp directory from src/lib/pcp directory.<br>
<br>What is still remaining.<br>==================<br>1- Need to decide the MemoryContext for memcache objects.<br>2- Watchdog and few rewrite function are still without the managers.<br>3- Replace all remaining occurrences of pool_error, pool_debug, and pool_log with appropriate ereport() calls<br>
4 -Code cleanup<br></div></div><div><br></div><div><p style="font-family:arial,sans-serif;font-size:13px">Reviews comments and suggestions are most welcome</p></div><div><br></div><div>Thanks</div><div>Usama</div><div><br>
</div></div>
</blockquote></div>