<div dir="ltr">Hi Tatsuo<div><br><div>I have rebased the EXCEPTION_MGR branch to current master, please find the updated patch generated after rebasing.</div><div><br></div><div>Thanks</div><div>Muhammad Usama<br><div class="gmail_extra">
<br><br><div class="gmail_quote">On Tue, Feb 11, 2014 at 11:17 AM, Tatsuo Ishii <span dir="ltr"><<a href="mailto:ishii@postgresql.org" target="_blank">ishii@postgresql.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Usama,<br>
<br>
I have checked EXCEPTION_MGR branch and it seems it is far behind main<br>
branch. The last patch brought to the EXCEPTION_MGR was dated<br>
2013/12/19. Can you please rebase the branch?<br>
<br>
Best regards,<br>
--<br>
Tatsuo Ishii<br>
SRA OSS, Inc. Japan<br>
English: <a href="http://www.sraoss.co.jp/index_en.php" target="_blank">http://www.sraoss.co.jp/index_en.php</a><br>
Japanese: <a href="http://www.sraoss.co.jp" target="_blank">http://www.sraoss.co.jp</a><br>
<br>
From: Muhammad Usama <<a href="mailto:m.usama@gmail.com">m.usama@gmail.com</a>><br>
Subject: penultimate patch for exception and memory manager ( EXCEPTION_MGR branch)<br>
Date: Mon, 10 Feb 2014 19:53:41 +0500<br>
Message-ID: <CAEJvTzUZHKKHjz-ZvYaAsviwVVBKSoX-ByNq9rhANO1zPJYR=<a href="mailto:w@mail.gmail.com">w@mail.gmail.com</a>><br>
<div class=""><div class="h5"><br>
> Please find the penultimate patch for integration of memory and exception<br>
> manager APIs into pgpool.<br>
> The patch is generated on the EXCEPTION_MGR development branch and<br>
> 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(),<br>
> pool_debug() and pool_log() function calls to ereport(ERROR,..)<br>
> ereport(DEBUG,..) and ereport(LOG,..) and it would be little time consuming<br>
> to review the patch. Although all the above also needs the thorough review,<br>
> as replacing pool_error() with ereport(ERROR) or ereport(FATAL) is just not<br>
> a cosmetic but changes the flow of code, but there are few things, that<br>
> 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<br>
> the life cycle of each object and making sure the object is created in the<br>
> proper MemoryContext. Here is the summary of some important objects and<br>
> their residences.<br>
><br>
> Some Important Memory Contexts<br>
> ============================<br>
><br>
> ProcessLoopContext:<br>
> This context resets at every main loop iteration of a process<br>
><br>
> TopMemoryContext:<br>
> This context is same as PostgreSQL's TopMemoryContext and lives for a life<br>
> time of process.<br>
><br>
> ErrorContext:<br>
> Same as PostgreSQL's ErrorContext and used for error processing.<br>
><br>
> QueryContext:<br>
> 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<br>
> lives for a single iteration of main child process loop.<br>
> 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<br>
> TopMemoryContext which lives throughout the process life time.<br>
><br>
> Child Frontend connection:<br>
> Frontend connection object is placed in the ProcessLoopContext since new<br>
> frontend connection is created at every main loop iteration of pgpool child<br>
> process.<br>
><br>
> PCP Frontend connection:<br>
> This object can live till the pcp process so the object for pcp frontend is<br>
> created in TopMemoryContext.<br>
><br>
> new configuration parameters<br>
> ========================<br>
><br>
> The patch also adds three new configuration parameters to control the error<br>
> reporting style and details.<br>
> Parameters names and their behaviours are borrowed from PostgreSQL.<br>
><br>
> int log_error_verbosity; /* controls how much detail about error should<br>
> be emitted */<br>
><br>
> int client_min_messages; /*controls which message should be sent to<br>
> client */<br>
><br>
> int log_min_messages; /*controls which message should be emitted to<br>
> server log */<br>
><br>
><br>
> Some other notable changes introduced by the patch.<br>
> ==========================================<br>
><br>
> The patch changes the error reporting behaviour and now pgpool-II tries to<br>
> send all the error and log messages to the connected frontend clients<br>
> (controllable by "client_min_messages" configuration parameter ).<br>
><br>
> The patch added an extra call back "on_system_exit" to the elog API, which<br>
> is not present in the PostgreSQL.<br>
> The call back is called at system exit by elog API just before calling the<br>
> "on_shmem_exit" call backs.<br>
> "on_system_exit" is a single call back and can be used to clean up things<br>
> which are dependent on shared memory.<br>
><br>
> "repalloc()" behaviour in PostgreSQL palloc API is little different from<br>
> C-API counterpart "realloc()".<br>
> ("realloc()" behaves as "malloc()" if ptr argument is NULL. While<br>
> "repalloc()" does not works on NULL pointers)<br>
> So I have changed the behaviour of "repalloc()" to make it more consistent<br>
> with C-API.<br>
><br>
> The patch makes the libpcp exclusive for the tool binaries only (compile<br>
> with POOL_PRIVATE flag ). pgpool binary no longer has the dependancy on the<br>
> lib, and uses the pcp_stream.c function directly.<br>
> For this new arrangement the patch also rearranges the source code<br>
> organisation and moves the pcp_stream.c and pcp_error.c files to<br>
> 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<br>
> pool_log with appropriate ereport() calls<br>
> 4 -Code cleanup<br>
><br>
> Reviews comments and suggestions are most welcome<br>
><br>
> Thanks<br>
> Usama<br>
</div></div></blockquote></div><br></div></div></div></div>