Hi,
Got different problem with DEALLOCATED then other one here. After few
hours (4-5h) normal working start see alot DEALLOCATED process at
pgpool and all db backends got such errors.
#v+
STATEMENT: DEALLOCATE "pdo_pgsql_stmt_8036eec4"
ERROR: prepared statement "pdo_pgsql_stmt_8063113c" does no
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 yo
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
> 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
Pgpool-general@pgfoundry.org
http://pgfoundry.o
Hi Tatsuo,
filtered logs are attached.
Can you validate the patches applied?
Thanks,
Agustín Almonte F.
pgpool_pid11723.log
Description: Binary data
El 25-09-2009, a las 4:00, Tatsuo Ishii escribió:
Xavier,
Thanks for analyzing and patches! I don't know what 0x004905 is
either. C
Tatsuo,
I think we found what the problem was. During the reset of a backend
the pgpool process send a BEGIN command to start a transaction and
expects to receive a message kind 'N', 'E', 'C' or 'Z', but in our
case the backend sends something different ( 0x004905 ). The
process interprets p
Xavier,
Thanks for analyzing and patches! I don't know what 0x004905 is
either. Can you send me the log?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
> Tatsuo,
>
> I think we found what the problem was. During the reset of a backend
> the pgpool process send a BEGIN command to start a transaction a
