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
> > What kind of problem do you have with DISCARD ALL?
>
> I'm not sure I do have a problem with DISCARD ALL anymore, so sorry for the
> confusion, I changed it back because it was just another variable I wanted to
> exclude.
>
> AFAIK this resolved problems for us when there was a bug with pg
--- On Wed, 23/9/09, Tatsuo Ishii wrote:
> Ok, I think for some reason DEALLOCATE fails and the
> internal list
> which manages prepared objects is not updated, and same
> request is
> issued over and over again. I need to know why DEALLOCATE
> fails, but
> at least we should prepare for this k
Agustín,
> > > Hi
> > >
> > > We applied the patch with the same result. After some
> > seconds child
> > > processes go into DEALLOCATE state until pgpool gets
> > completly hang.
[snip]
> > > i attached the complete log for one of these
> > processes.
> > >
> > >
> > > Please any test we
--- On Wed, 23/9/09, Tatsuo Ishii wrote:
> > Hi
> >
> > We applied the patch with the same result. After some
> seconds child
> > processes go into DEALLOCATE state until pgpool gets
> completly hang.
> >
> > root
> 592 569 4 23:31
> ? 00:00:57 pgpool: sess
> sess
> > 127.0.0
> Hi
>
> We applied the patch with the same result. After some seconds child
> processes go into DEALLOCATE state until pgpool gets completly hang.
>
> root 592 569 4 23:31 ?00:00:57 pgpool: sess sess
> 127.0.0.1(56552) DEALLOCATE
> root 597 569 0 23:31 ?00:0
Oops. Wrong patch. Please try this one.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
> So far I suspect that your clients disconnects to pgpool but pgpool
> does not detect it for unknown reason and it's a source of problem.
>
> From your debug log:
>
> > 2009-09-12 00:46:16 ERROR: pid 17759: pool_flush_
So far I suspect that your clients disconnects to pgpool but pgpool
does not detect it for unknown reason and it's a source of problem.
From your debug log:
> 2009-09-12 00:46:16 ERROR: pid 17759: pool_flush_it: write failed (Broken
> pipe) offset: 0 wlen: 149
This means the connection between
Hi
Did you have the chance to analyze this issue?
We are doing some new test in our laboratory, adding more log to
provide you more details.
Any particular test we can do, to help your analisys?
Thanks
Agustín Almonte F.
El 13-09-2009, a las 18:02, Agustin Almonte Ferrada escribió:
Here is de pgpool.conf file without comments.
listen_addresses = '*'
port =
pcp_port = 9898
socket_dir = '/var/run/postgresql'
pcp_socket_dir = '/var/run/postgresql'
backend_socket_dir = '/var/run/postgresql'
pcp_timeout = 10
num_init_children = 150
max_pool = 2
child_life_time = 30
connecti
Still studying what's going on...
Can you show me pgpool.conf file?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
> Thanks Tatsuo for your reply.
>
> The diferences between backends are just data. We are working with
> pgpool 2.2.1 and some inserts/updates don't get to the second backend,
> always is
Thanks Tatsuo for your reply.
The diferences between backends are just data. We are working with
pgpool 2.2.1 and some inserts/updates don't get to the second backend,
always is the second backend wich has less data, so we are trying now
with version 2.2.4.
Here is the filtered log outpu
My guess is DEALLOCATE is being issued at end of session between
pgpool and PostgreSQL. For some reason PostgreSQL returns weired
packet kind 0x73 on node 0 and 0x84 on node 1.
Anyway, I need more information.
Do you find some errors in PostgreSQL log? What kind of difference are
there in your da
Hi,
I'm testing pgpool 2.2.4 with some problems i hope someone can
help me to figure out what the problem is.
I have two backends that unfortunately have diferences, that's the
initial scenario when i started pgpool, everything goes well for some
seconds but after a while a lot of er
20 matches
Mail list logo
