From: | Shay Rojansky <roji(at)roji(dot)org> |
---|---|
To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Odd query execution behavior with extended protocol |
Date: | 2015-10-03 09:03:45 |
Message-ID: | CADT4RqB8-FaVw+xSd_ESEA0HAb=2yXvuOZAc6AxMq5j+ZkZnFQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2015-10-03 11:21:36 | Re: ON CONFLICT issues around whole row vars, |
Previous Message | Amit Kapila | 2015-10-03 06:27:20 | Re: WIP: Rework access method interface |