Re: [HACKERS] Odd query execution behavior with extended protocol

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

Re: [HACKERS] Odd query execution behavior with extended protocol

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,

Re: [HACKERS] Odd query execution behavior with extended protocol

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

Re: [HACKERS] Odd query execution behavior with extended protocol

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

Re: [HACKERS] Odd query execution behavior with extended protocol

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

Re: [HACKERS] Odd query execution behavior with extended protocol

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

Re: [HACKERS] Odd query execution behavior with extended protocol

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

Re: [HACKERS] Odd query execution behavior with extended protocol

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 > >>

Re: [HACKERS] Odd query execution behavior with extended protocol

> > > 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

Re: [HACKERS] Odd query execution behavior with extended protocol

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

Re: [HACKERS] Odd query execution behavior with extended protocol

> > > 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

Re: [HACKERS] Odd query execution behavior with extended protocol

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

Re: [HACKERS] Odd query execution behavior with extended protocol

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

Re: [HACKERS] Odd query execution behavior with extended protocol

> > 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

Re: [HACKERS] Odd query execution behavior with extended protocol

> > 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

Re: [HACKERS] Odd query execution behavior with extended protocol

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 >

Re: [HACKERS] Odd query execution behavior with extended protocol

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