On Sat, 8 Dec 2018 at 08:18, Tatsuo Ishii wrote:
> >> > Curious what client is this that is violating the protocol.
> >>
> >> I heard it was a Java program.
> >>
> >
> > This is not surprising there are a proliferation of non-blocking
> > implementations,
> > probably approaching 10 different
>> > Curious what client is this that is violating the protocol.
>>
>> I heard it was a Java program.
>>
>
> This is not surprising there are a proliferation of non-blocking
> implementations,
> probably approaching 10 different implementations now.
Do you think some of the implementations may
On Sat, 8 Dec 2018 at 07:50, Tatsuo Ishii wrote:
> > Curious what client is this that is violating the protocol.
>
> I heard it was a Java program.
>
This is not surprising there are a proliferation of non-blocking
implementations,
probably approaching 10 different implementations now.
Dave
> Curious what client is this that is violating the protocol.
I heard it was a Java program.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
>Curious what client is this that is violating the protocol.
I stand corrected: that is not a violation, however client might get
unexpected failure of query(begin) in a rare case of close(s1) or close(s2)
fail.
Vladimir
On Sat, 8 Dec 2018 at 05:16, Tatsuo Ishii wrote:
> > Tatsuo>responses of a simple query do not include CloseComplete
> >
> > Tatsuo, where do you get the logs from?
>
> As I said, pgproto.
>
> https://github.com/tatsuo-ishii/pgproto
>
> > I guess you are just confused by the PRINTED order of the
> Tatsuo>responses of a simple query do not include CloseComplete
>
> Tatsuo, where do you get the logs from?
As I said, pgproto.
https://github.com/tatsuo-ishii/pgproto
> I guess you are just confused by the PRINTED order of the messages in the
> log.
> Note: wire order do not have to be
Tatsuo>responses of a simple query do not include CloseComplete
Tatsuo, where do you get the logs from?
I guess you are just confused by the PRINTED order of the messages in the
log.
Note: wire order do not have to be exactly the same as the order in the log
since messages are buffered, then
> Tatsuo Ishii writes:
>> While looking into an issue of Pgpool-II, I found an interesting
>> behavior of a PostgreSQL client.
>> Below is a trace from pgproto to reproduce the client's behavior.
>
>> It starts a transacton.
>
>> FE=> Parse(stmt="S1", query="BEGIN")
>> FE=> Bind(stmt="S1",
Tatsuo Ishii writes:
> While looking into an issue of Pgpool-II, I found an interesting
> behavior of a PostgreSQL client.
> Below is a trace from pgproto to reproduce the client's behavior.
> It starts a transacton.
> FE=> Parse(stmt="S1", query="BEGIN")
> FE=> Bind(stmt="S1", portal="")
>
While looking into an issue of Pgpool-II, I found an interesting
behavior of a PostgreSQL client.
Below is a trace from pgproto to reproduce the client's behavior.
It starts a transacton.
FE=> Parse(stmt="S1", query="BEGIN")
FE=> Bind(stmt="S1", portal="")
FE=> Execute(portal="")
:
Commit the
11 matches
Mail list logo
