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 P1/D1/B1/E1/P2/D2/B2/E2, and the first query has a large resultset, > PostgreSQL may block writing the resultset, since Npgsql isn't reading it > at that point. Npgsql on its part may get stuck writing the second query > (if it's big enough) since PostgreSQL isn't reading on its end (thanks to > Emil Lenngren for pointing this out originally). >
That part does sound like a problem that we have no good answer to. Sounds worth starting a new thread on that. > Of course this isn't an excuse for anything, we're looking into ways of > solving this problem differently in our driver implementation. > > Shay > > On Thu, Jun 11, 2015 at 6:17 PM, Simon Riggs <si...@2ndquadrant.com> > wrote: > >> 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 Riggs http://www.2ndQuadrant.com/ <http://www.2ndquadrant.com/> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
