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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Shay Rojansky <roji(at)roji(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Entities created in one query not available in another in extended protocol
Date: 2015-06-11 14:34:15
Message-ID: CA+TgmoYDTapay1w_0hwoES1+UhZ-QoH5fSGhih_H=vHTJwdiBQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jun 11, 2015 at 5:38 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On 11 June 2015 at 11:20, Shay Rojansky <roji(at)roji(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kohei KaiGai 2015-06-11 14:40:03 Re: DBT-3 with SF=20 got failed
Previous Message Tomas Vondra 2015-06-11 14:33:17 Re: DBT-3 with SF=20 got failed