Oh ok. Yes if the backend returns E, instead of C, the callback is not called. You are right. Also I find that if the callback is called to remove, say S_1, del_prepared_list() does not remove next prepared objectm say S_2. So calling del_prepared_list() always seems to be harmless. I will apply your patches with minor modifications (mostly just add comments). Thanks! -- Tatsuo Ishii SRA OSS, Inc. Japan
> It seems that under certain circumstances the callback that is > registered in SimpleQuery() is not called. Does > SimpleForwardToFrontend() and so del_prepared_list() not get called > when an error (kind 'E') is received from the backend ? > > This log fragment shows how two statements where deallocated and > deleted from prepared_list, but then the next one wasn't after getting > an error (kind 'E') response from the backend, which causes the > process to get into an infinite loop. > > > > 2009-09-26 00:45:31 DEBUG: pid 24289: reset_backend: entrando con qcnt 3 > 2009-09-26 00:45:31 DEBUG: pid 24289: reset_backend: qn = 3 > 2009-09-26 00:45:31 DEBUG: pid 24289: reset_backend: prepared_list.cnt = 4 > 2009-09-26 00:45:31 LOG: pid 24289: statement: DEALLOCATE "S_1" > 2009-09-26 00:45:31 DEBUG: pid 24289: detect_error: kind: C > 2009-09-26 00:45:31 DEBUG: pid 24289: detect_error: kind: C > 2009-09-26 00:45:31 DEBUG: pid 24289: detect_error: kind: C > 2009-09-26 00:45:31 DEBUG: pid 24289: detect_error: kind: C > 2009-09-26 00:45:31 DEBUG: pid 24289: detect_error: kind: C > 2009-09-26 00:45:31 DEBUG: pid 24289: detect_error: kind: C > 2009-09-26 00:45:31 DEBUG: pid 24289: detect_error: kind: C > 2009-09-26 00:45:31 DEBUG: pid 24289: detect_error: kind: C > 2009-09-26 00:45:31 DEBUG: pid 24289: reset_backend: entrando con qcnt 4 > 2009-09-26 00:45:31 DEBUG: pid 24289: reset_backend: qn = 3 > 2009-09-26 00:45:31 DEBUG: pid 24289: reset_backend: prepared_list.cnt = 3 > 2009-09-26 00:45:31 LOG: pid 24289: statement: DEALLOCATE "S_2" > 2009-09-26 00:45:31 DEBUG: pid 24289: detect_error: kind: C > 2009-09-26 00:45:31 DEBUG: pid 24289: detect_error: kind: C > 2009-09-26 00:45:31 DEBUG: pid 24289: detect_error: kind: C > 2009-09-26 00:45:31 DEBUG: pid 24289: detect_error: kind: C > 2009-09-26 00:45:31 DEBUG: pid 24289: detect_error: kind: C > 2009-09-26 00:45:31 DEBUG: pid 24289: detect_error: kind: C > 2009-09-26 00:45:31 DEBUG: pid 24289: detect_error: kind: C > 2009-09-26 00:45:31 DEBUG: pid 24289: detect_error: kind: C > 2009-09-26 00:45:31 DEBUG: pid 24289: reset_backend: entrando con qcnt 5 > 2009-09-26 00:45:31 DEBUG: pid 24289: reset_backend: qn = 3 > 2009-09-26 00:45:31 DEBUG: pid 24289: reset_backend: prepared_list.cnt = 2 > 2009-09-26 00:45:31 LOG: pid 24289: statement: DEALLOCATE "S_1" > 2009-09-26 00:45:31 DEBUG: pid 24289: detect_error: kind: C > 2009-09-26 00:45:31 DEBUG: pid 24289: detect_error: kind: C > 2009-09-26 00:45:31 DEBUG: pid 24289: detect_error: kind: E > 2009-09-26 00:45:31 DEBUG: pid 24289: detect_error: kind: E > 2009-09-26 00:45:31 DEBUG: pid 24289: detect_error: kind: E > 2009-09-26 00:45:31 DEBUG: pid 24289: detect_error: kind: E > 2009-09-26 00:45:31 DEBUG: pid 24289: detect_error: kind: Z > 2009-09-26 00:45:31 DEBUG: pid 24289: detect_error: kind: Z > 2009-09-26 00:45:31 DEBUG: pid 24289: detect_error: kind: C > 2009-09-26 00:45:31 DEBUG: pid 24289: detect_error: kind: C > 2009-09-26 00:45:31 DEBUG: pid 24289: reset_backend: entrando con qcnt 6 > 2009-09-26 00:45:31 DEBUG: pid 24289: reset_backend: qn = 3 > 2009-09-26 00:45:31 DEBUG: pid 24289: reset_backend: prepared_list.cnt = 2 > 2009-09-26 00:45:31 LOG: pid 24289: statement: DEALLOCATE "S_1" > 2009-09-26 00:45:31 DEBUG: pid 24289: detect_error: kind: C > 2009-09-26 00:45:31 DEBUG: pid 24289: detect_error: kind: C > 2009-09-26 00:45:31 DEBUG: pid 24289: detect_error: kind: E > 2009-09-26 00:45:31 DEBUG: pid 24289: detect_error: kind: E > 2009-09-26 00:45:31 DEBUG: pid 24289: detect_error: kind: E > 2009-09-26 00:45:31 DEBUG: pid 24289: detect_error: kind: E > 2009-09-26 00:45:31 DEBUG: pid 24289: detect_error: kind: Z > 2009-09-26 00:45:31 DEBUG: pid 24289: detect_error: kind: Z > 2009-09-26 00:45:31 DEBUG: pid 24289: detect_error: kind: C > 2009-09-26 00:45:31 DEBUG: pid 24289: detect_error: kind: C > 2009-09-26 00:45:31 DEBUG: pid 24289: reset_backend: entrando con qcnt 7 > 2009-09-26 00:45:31 DEBUG: pid 24289: reset_backend: qn = 3 > 2009-09-26 00:45:31 DEBUG: pid 24289: reset_backend: prepared_list.cnt = 2 > > > I'll try to do more tests in order to produce a patch for this. In > the meantime I'm attaching the full log for farther examination. > > > On Fri, Sep 25, 2009 at 8:47 PM, Tatsuo Ishii <[email protected]> wrote: > > Hum. > > > > --- pool_process_query.c 23 Sep 2009 11:39:10 -0000 1.141.2.20 > > +++ pool_process_query.c 25 Sep 2009 19:48:39 -0000 > > @@ -2178,6 +2178,7 @@ > > reset_prepared_list(&prepared_list); > > return -1; > > } > > + del_prepared_list(&prepared_list, > > prepared_list.portal_list[0]); > > return 1; > > } > > > > This part does not look good. > > > > /* Delete from prepared list */ > > if (send_deallocate(backend, &prepared_list, 0)) > > { > > /* Deallocate failed. We are in unknown state. Ask > > caller > > * to reset backend connection. > > */ > > reset_prepared_list(&prepared_list); > > return -1; > > } > > del_prepared_list(&prepared_list, > > prepared_list.portal_list[0]); > > > > send_deallocate() not only sends DEALLOCATE to the backend but > > register a callback to call del_prepared_list() after DEALLOCATE > > succeeds. Thus if send_deallocate() succeeded, del_prepared_list() > > should have been called. Calling del_prepared_list() in your pacth is > > not only neccessary but removes prepared object withput sending > > DEALLOCATE to backend, no? > > -- > > Tatsuo Ishii > > SRA OSS, Inc. Japan > > > >> Tatsuo, > >> > >> I'm attaching a single patch with both of the changes I sent > >> previously. It was made against the V2_2_STABLE branch (not HEAD), > >> because it depends on the patch from Sep 23 11:39:10. > >> > >> Thanks for all your patience. > >> > >> Cheers > >> > >> On Fri, 2009-09-25 at 21:23 +0900, Tatsuo Ishii wrote: > >> > > Hi Tatsuo, > >> > > > >> > > filtered logs are attached. > >> > > >> > Thanks. > >> > > >> > > Can you validate the patches applied? > >> > > >> > The patches look good. I'm going to apply. > >> > -- > >> > Tatsuo Ishii > >> > SRA OSS, Inc. Japan > > _______________________________________________ Pgpool-general mailing list [email protected] http://pgfoundry.org/mailman/listinfo/pgpool-general
