Re: Odd query execution behavior with extended protocol
От | Charles Clavadetscher |
---|---|
Тема | Re: Odd query execution behavior with extended protocol |
Дата | |
Msg-id | 040501d0fe6f$9c60a9f0$d521fdd0$@swisspug.org обсуждение исходный текст |
Ответ на | Odd query execution behavior with extended protocol (Shay Rojansky <roji@roji.org>) |
Ответы |
Re: Odd query execution behavior with extended protocol
|
Список | pgsql-hackers |
Hello > Npgsql supports sending multiple SQL statements in a single packet via the extended protocol. This works fine, but whenthe 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 statement is not committed, assuming that the two statements run in different transactions. > 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 I never used Npgsql so I don't know if there is something missing there. Would you need an explicit commit before closingMQ0? Also I am not in clear what "statement=unnamed" means, but it is used twice. Is it possible that the update is overwrittenwith select before it executes? Just some thoughts, as I said I know nothing of Npgsql. BTW: Do you see the change after update in your DB if you look into it with another tool (e.g. psql)? Charles
В списке pgsql-hackers по дате отправления: