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

From Robert Haas
Subject Re: Entities created in one query not available in another in extended protocol
Date
Msg-id CA+TgmoYDTapay1w_0hwoES1+UhZ-QoH5fSGhih_H=vHTJwdiBQ@mail.gmail.com
Whole thread Raw
In response to Re: Entities created in one query not available in another in extended protocol  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
On Thu, Jun 11, 2015 at 5:38 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On 11 June 2015 at 11:20, Shay Rojansky <roji@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 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?

Actually, I think I've seen this before.   The code that handles the
Sync message does this:
                       case 'S':                       /* sync */
pq_getmsgend(&input_message);                              finish_xact_command();
send_ready_for_query= true;                               break;
 

finish_xact_command() calls CommitTransactionCommand(), which does
CommandCounterIncrement() or CommitTransaction() as appropriate.  So
without the Sync, I think it's expected that you don't see the results
of the previous command.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Kohei KaiGai
Date:
Subject: Re: DBT-3 with SF=20 got failed
Next
From: Tomas Vondra
Date:
Subject: Re: DBT-3 with SF=20 got failed