Re: Entities created in one query not available in another in extended protocol - Mailing list pgsql-hackers

From Shay Rojansky
Subject Re: Entities created in one query not available in another in extended protocol
Date
Msg-id CADT4RqDs0fuAqChOm6eLZa0gpdz3wPCmGtwVOfyrP2eA4b8xeQ@mail.gmail.com
Whole thread Raw
In response to Re: Entities created in one query not available in another in extended protocol  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Entities created in one query not available in another in extended protocol  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
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 <tgl@sss.pgh.pa.us> wrote:
Simon Riggs <simon@2ndQuadrant.com> writes:
> On 11 June 2015 at 11:20, Shay Rojansky <roji@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

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Entities created in one query not available in another in extended protocol
Next
From: Tom Lane
Date:
Subject: Re: DBT-3 with SF=20 got failed