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

From Charles Clavadetscher
Subject Re: Odd query execution behavior with extended protocol
Date
Msg-id 040501d0fe6f$9c60a9f0$d521fdd0$@swisspug.org
Whole thread Raw
In response to Odd query execution behavior with extended protocol  (Shay Rojansky <roji@roji.org>)
Responses Re: Odd query execution behavior with extended protocol  (Shay Rojansky <roji@roji.org>)
List 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 by date:

Previous
From: Noah Misch
Date:
Subject: Re: 9.3.9 and pg_multixact corruption
Next
From: Pavel Stehule
Date:
Subject: check fails on Fedora 23