Re: [HACKERS] Entities created in one query not available in another in extended protocol

2015-06-14 Thread Shay Rojansky
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

Re: [HACKERS] Entities created in one query not available in another in extended protocol

2015-06-14 Thread Shay Rojansky
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

Re: [HACKERS] Entities created in one query not available in another in extended protocol

2015-06-12 Thread Sehrope Sarkuni
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

Re: [HACKERS] Entities created in one query not available in another in extended protocol

2015-06-12 Thread Simon Riggs
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

[HACKERS] Entities created in one query not available in another in extended protocol

2015-06-11 Thread Shay Rojansky
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

Re: [HACKERS] Entities created in one query not available in another in extended protocol

2015-06-11 Thread Simon Riggs
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

Re: [HACKERS] Entities created in one query not available in another in extended protocol

2015-06-11 Thread Tom Lane
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

Re: [HACKERS] Entities created in one query not available in another in extended protocol

2015-06-11 Thread Andres Freund
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

Re: [HACKERS] Entities created in one query not available in another in extended protocol

2015-06-11 Thread Shay Rojansky
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

Re: [HACKERS] Entities created in one query not available in another in extended protocol

2015-06-11 Thread Tom Lane
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

Re: [HACKERS] Entities created in one query not available in another in extended protocol

2015-06-11 Thread Robert Haas
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

Re: [HACKERS] Entities created in one query not available in another in extended protocol

2015-06-11 Thread Shay Rojansky
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,

Re: [HACKERS] Entities created in one query not available in another in extended protocol

2015-06-11 Thread Simon Riggs
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