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

From Tom Lane
Subject Re: Entities created in one query not available in another in extended protocol
Date
Msg-id 18426.1434034231@sss.pgh.pa.us
Whole thread Raw
In response to Re: Entities created in one query not available in another in extended protocol  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Entities created in one query not available in another in extended protocol  (Shay Rojansky <roji@roji.org>)
Re: Entities created in one query not available in another in extended protocol  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
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: Kohei KaiGai
Date:
Subject: Re: DBT-3 with SF=20 got failed
Next
From: Shay Rojansky
Date:
Subject: Re: Entities created in one query not available in another in extended protocol