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 behavior after reordering the messages (assuming we do reorder).
Thanks for your inputs... On Thu, Jun 11, 2015 at 5:50 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > 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 second one can't query that > entity > >> (not found). This isn't terribly important but does seem a bit odd, I > >> wanted to make sure you're aware of this. > > > Sounds somewhat unlikely, but thank you for the report. Can we see a test > > case? > > > Most commonly in such cases the first request failed and error messages > > weren't checked before running second message. > > I'm wondering if it was really more like > Parse/Parse/Bind/Bind/Execute/Execute/Sync, in which case the described > behavior wouldn't be too surprising at all. > > 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 CommandCounterIncrement in exec_execute_message ... > > regards, tom lane >
