From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
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:50:31 |
Message-ID: | 18426.1434034231@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> On 11 June 2015 at 11:20, Shay Rojansky <roji(at)roji(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Kohei KaiGai | 2015-06-11 14:50:43 | Re: DBT-3 with SF=20 got failed |
Previous Message | Alvaro Herrera | 2015-06-11 14:45:49 | Re: skipping pg_log in basebackup (was Re: pg_basebackup and pg_stat_tmp directory) |