[Pgpool-general] pgpool 2.2.4: DEALLOCATED children

Xavier Noguer xnoguer at antica.cl
Sat Sep 26 06:32:40 UTC 2009 

 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 <ishii at sraoss.co.jp> 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
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgpool_pid_2489.log.gz
Type: application/x-gzip
Size: 32714 bytes
Desc: not available
URL: <http://pgfoundry.org/pipermail/pgpool-general/attachments/20090926/55d4bb53/attachment-0001.bin>

More information about the Pgpool-general mailing list