Odd query execution behavior with extended protocol - Mailing list pgsql-hackers

From Shay Rojansky
Subject Odd query execution behavior with extended protocol
Date
Msg-id CADT4RqB8-FaVw+xSd_ESEA0HAb=2yXvuOZAc6AxMq5j+ZkZnFQ@mail.gmail.com
Whole thread Raw
Responses Re: Odd query execution behavior with extended protocol  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
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 as if the UPDATE hasn't yet occurred.

The exact messages send by Npgsql are:

Parse (UPDATE data SET name='foo' WHERE id=1), statement=unnamed
Describe (statement=unnamed)
Bind (statement=unnamed, portal=MQ0)
Parse (SELECT * FROM data WHERE id=1), statement=unnamed
Describe (statement=unnamed)
Bind (statement=unnamed, portal=MQ1)
Execute (portal=MQ0)
Close (portal=MQ0)
Execute (portal=MQ1)
Close (portal=MQ1)
Sync

Instead of returning the expected 'foo' value set in the first command's UPDATE, I'm getting whatever value was previously there.
Note that this happen regardless of whether a transaction is already set and of the isolation level.

Is this the expected behavior, have I misunderstood the protocol specs?

Thanks for your help, and please let me know if you need any more info.

Shay

pgsql-hackers by date:

Previous
From: Merlin Moncure
Date:
Subject: Re: No Issue Tracker - Say it Ain't So!]
Next
From: Nathan Wagner
Date:
Subject: Re: No Issue Tracker - Say it Ain't So!