Re: [Postgres-xc-developers] GTM Standby Crash

[Pavan D. <pav...@gm...>]

On Thu, Mar 7, 2013 at 5:57 PM, Nikhil Sontakke <ni...@st...> wrote:
> Hi,
>
> PFA, patch which fixes an obnoxious crash in GTM Standby. This one was
> a tough nut to crack down. The crash is as below
>
> Program terminated with signal 11, Segmentation fault.
> #0  0x00000000004253c9 in gtm_lappend ()
> Missing separate debuginfos, use: debuginfo-install
> glibc-2.12-1.80.el6_3.6.x86_64 libgcc-4.4.6-4.el6.x86_64
> (gdb) bt
> #0  0x00000000004253c9 in gtm_lappend ()
> #1  0x000000000040ad77 in GTM_BkupBeginTransactionGetGXIDMulti.clone.0 ()
> #2  0x000000000040aedb in ProcessBkupBeginTransactionGetGXIDCommand ()
> #3  0x000000000040417c in GTM_ThreadMain ()
>
>
>
> IMHO, using TopMemoryContext to mean the top context of each thread is
> pretty confusing. Bad choice of name for the memory context according
> to me. Maybe we could have avoided this crash if we had used a
> different name for the context.
>
> This "TopMemoryContext" goes away when that thread goes away. So ain't
> nothing TOP about it.

Well, let me at least try and defend because that's my baby :-) I
think I chose name TopTransactionContext because I wanted to give a
thread in GTM as much the same treatment as a process gets in
Postgres. So I stick to the same names, but invented TopMost to mean
the context which is global to the GTM process. My idea was and still
is that we should avoid using TopMost as much as we can because that
memory leaks will be hard to plug-in. Remember, we expect GTM to run
as long as any one component of the cluster is running.. which pretty
much means forever because while any one component of the cluster can
go down, but not the entire cluster.

But if its causing confusion, I won't mind adding a code commentary to
explain the difference. Clearly my fault.

Thanks,
Pavan

-- 
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee