Tom, I agree this is entirely a client-side issue. Regardless, as Simon
says it would be useful to have some documentation for client implementors.
Sehrope, thanks for the JDBC link! I was actually thinking of going about
it another way in Npgsql:
1. Send messages normally until the first
On Sun, Jun 14, 2015 at 6:31 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Shay Rojansky r...@roji.org writes:
[ rely on non-blocking sockets to avoid deadlock ]
Yeah, that's pretty much the approach libpq has taken: write (or read)
when you can, but press on when you can't.
Good to hear.
The
The JDBC driver tries to handle this by estimating how much data has been
buffered. It mainly comes up when executing batch INSERTS as a large number
of statements may be sent to the backend prior to reading back any results.
There's a nice write up of the potential deadlock and the driver's
On 11 June 2015 at 22:12, Shay Rojansky r...@roji.org wrote:
Thanks everyone for your time (or rather sorry for having wasted it).
Just in case it's interesting to you... The reason we implemented things
this way is in order to avoid a deadlock situation - if we send two queries
as
In Npgsql, the .NET driver for PostgreSQL, we've switched from simple to
extended protocol and have received a user complaint.
It appears that when we send two messages in an extended protocol (so two
Parse/Bind/Execute followed by a single Sync), where the first one creates
some entity
On 11 June 2015 at 11:20, Shay Rojansky r...@roji.org wrote:
In Npgsql, the .NET driver for PostgreSQL, we've switched from simple to
extended protocol and have received a user complaint.
It appears that when we send two messages in an extended protocol (so two
Parse/Bind/Execute followed by
Simon Riggs si...@2ndquadrant.com writes:
On 11 June 2015 at 11:20, Shay Rojansky r...@roji.org wrote:
It appears that when we send two messages in an extended protocol (so two
Parse/Bind/Execute followed by a single Sync), where the first one creates
some entity (function, table), and the
On 2015-06-11 10:50:31 -0400, Tom Lane wrote:
I do note that if a transaction is implicitly started to execute these
messages, it's not closed until Sync. But that should only affect the
visibility of the results to other sessions, not to the current one.
There's definitely a
I just understood the same thing Tom wrote, yes, Npgsql (currently) sends
Parse for the second command before sending Execute for the first one. I
will look into that implementation decision. It might be worth looking into
Simon's comment though, I'll report if I still see the same problematic
Andres Freund and...@anarazel.de writes:
On 2015-06-11 10:50:31 -0400, Tom Lane wrote:
I do note that if a transaction is implicitly started to execute these
messages, it's not closed until Sync. But that should only affect the
visibility of the results to other sessions, not to the current
On Thu, Jun 11, 2015 at 5:38 AM, Simon Riggs si...@2ndquadrant.com wrote:
On 11 June 2015 at 11:20, Shay Rojansky r...@roji.org wrote:
In Npgsql, the .NET driver for PostgreSQL, we've switched from simple to
extended protocol and have received a user complaint.
It appears that when we send
Thanks everyone for your time (or rather sorry for having wasted it).
Just in case it's interesting to you... The reason we implemented things
this way is in order to avoid a deadlock situation - if we send two queries
as P1/D1/B1/E1/P2/D2/B2/E2, and the first query has a large resultset,
On 11 June 2015 at 16:56, Shay Rojansky r...@roji.org wrote:
Npgsql (currently) sends Parse for the second command before sending
Execute for the first one.
Look no further than that.
--
Simon Riggshttp://www.2ndQuadrant.com/
http://www.2ndquadrant.com/
PostgreSQL
13 matches
Mail list logo