On Tue, Oct 6, 2015 at 6:18 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Oct 6, 2015 at 6:10 PM, Tom Lane wrote:
>>> I'm concerned though whether this would amount to a protocol break.
>
>> Me, too.
>
> There are enough CCI's floating around the code that there may not
> actually be any
Robert Haas writes:
> On Tue, Oct 6, 2015 at 6:10 PM, Tom Lane wrote:
>> I'm concerned though whether this would amount to a protocol break.
> Me, too.
There are enough CCI's floating around the code that there may not
actually be any observable problem, at least not in typical cases.
That woul
On Tue, Oct 6, 2015 at 6:10 PM, Tom Lane wrote:
> I'm concerned though whether this would amount to a protocol break.
Me, too.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To m
Robert Haas writes:
> On Tue, Oct 6, 2015 at 5:53 PM, Tom Lane wrote:
>> I dunno, if you close a portal before you've gotten CommandComplete,
>> should you expect that all its actions were taken? Arguably, that
>> should be more like a ROLLBACK.
> I dunno either, but a rollback would undo every
On Tue, Oct 6, 2015 at 5:53 PM, Tom Lane wrote:
> Robert Haas writes:
>> From looking at the code, it appears to me that if the Execute is run
>> to completion, then its results will be seen by future statements, but
>> if the portal is closed earlier, then not. See the end of
>> exec_execute_me
Robert Haas writes:
> From looking at the code, it appears to me that if the Execute is run
> to completion, then its results will be seen by future statements, but
> if the portal is closed earlier, then not. See the end of
> exec_execute_message. The handler for the Close message (inside
> Pos
On Sat, Oct 3, 2015 at 5:03 AM, Shay Rojansky wrote:
> Hi hackers, some odd behavior has been reported with Npgsql and I wanted to
> get your help.
>
> Npgsql supports sending multiple SQL statements in a single packet via the
> extended protocol. This works fine, but when the second query SELECTs
>
> > So you would suggest changing my message chain to send Bind right after
> > Execute, right? This would yield the following messages:
>
> > P1/P2/D1/B1/E1/D2/B2/E2/S (rather than the current
> > P1/D1/B1/P2/D2/B2/E1/C1/E2/C2/S)
>
> > This would mean that I would switch to using named statement
Hi hackers, some odd behavior has been reported with Npgsql and I wanted to
get your help.
Npgsql supports sending multiple SQL statements in a single packet via the
extended protocol. This works fine, but when the second query SELECTs a
value modified by the first's UPDATE, I'm getting a result a
Thanks for the help Tom and the others, I'll modify my sequence and report
if I encounter any further issues.
On Sun, Oct 4, 2015 at 7:36 PM, Tom Lane wrote:
> Shay Rojansky writes:
> >> To my mind there is not a lot of value in performing Bind until you
> >> are ready to do Execute. The only
Shay Rojansky writes:
>> Try adding a sync before the second execute.
> I tried inserting a Sync right before the second Execute, this caused an
> error with the message 'portal "MQ1" does not exist'.
> This seems like problematic behavior on its own, regardless of my issues
> here (Sync shouldn'
Shay Rojansky writes:
>> To my mind there is not a lot of value in performing Bind until you
>> are ready to do Execute. The only reason the operations are separated
>> in the protocol is so that you can do multiple Executes with a row limit
>> on each one, to retrieve a large query result in chu
>
> I'm fairly sure that the query snapshot is established at Bind time,
> which means that this SELECT will run with a snapshot that indeed
> does not see the effects of the UPDATE.
>
> To my mind there is not a lot of value in performing Bind until you
> are ready to do Execute. The only reason
>
> Try adding a sync before the second execute.
>
I tried inserting a Sync right before the second Execute, this caused an
error with the message 'portal "MQ1" does not exist'.
This seems like problematic behavior on its own, regardless of my issues
here (Sync shouldn't be causing an implicit clo
Shay Rojansky writes:
> Npgsql supports sending multiple SQL statements in a single packet via the
> extended protocol. This works fine, but when the second query SELECTs a
> value modified by the first's UPDATE, I'm getting a result as if the UPDATE
> hasn't yet occurred.
> The exact messages se
On October 4, 2015 2:50:10 PM GMT+02:00, Shay Rojansky wrote:
>>
>> > Npgsql supports sending multiple SQL statements in a single packet
>via
>> the extended protocol. This works fine, but when the second query
>SELECTs a
>> value modified by the first's UPDATE, I'm getting a result as if the
>> >
>
> > Npgsql supports sending multiple SQL statements in a single packet via
> the extended protocol. This works fine, but when the second query SELECTs a
> value modified by the first's UPDATE, I'm getting a result as if the
> > UPDATE hasn't yet occurred.
>
> Looks like the first updating stateme
Hello
> Npgsql supports sending multiple SQL statements in a single packet via the
> extended protocol. This works fine, but when the second query SELECTs a value
> modified by the first's UPDATE, I'm getting a result as if the
> UPDATE hasn't yet occurred.
Looks like the first updating statem
Hi hackers, some odd behavior has been reported with Npgsql and I'm sure
you can help.
Npgsql supports sending multiple SQL statements in a single packet via the
extended protocol. This works fine, but when the second query SELECTs a
value modified by the first's UPDATE, I'm getting a result as if
19 matches
Mail list logo
