From: Tom Lane <tgl@sss.pgh.pa.us>
To: matt.jibson@gmail.com
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17565: Extended query protocol incorrectly sets
 TBLOCK_STARTED even though multiple queries can be executed
In-reply-to: <17565-156f3bd8f262150f@postgresql.org>
References: <17565-156f3bd8f262150f@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Mon, 01 Aug 2022 20:12:00 -0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2185025.1659392478.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Mon, 01 Aug 2022 18:21:18 -0400
Message-ID: <2185026.1659392478@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2185026.1659392478%40sss.pgh.pa.us>
Precedence: bulk

PG Bug reporting form <noreply@postgresql.org> writes:
> The extended query protocol is most often used with the 4 messages in th=
e
> sequence: Parse, Bind, Execute, Sync. Parse, Bind, and Execute all call
> start_xact_command, which will change blockState to TBLOCK_STARTED. Howe=
ver
> it is within the protocol spec to instead do: Parse, Bind, Execute, Pars=
e,
> Bind, Execute, Sync. That is: issue two query executions and then a Sync=
.
> The Npgsql driver does exactly this at its startup.

> The doc comment for TBLOCK_STARTED says "running single-query transactio=
n",
> but this is a case where a driver can escape that restriction which is
> assumed by the rest of the code. For example, there are various things
> differentiate between STARTED and INPROGRESS or IMPLICIT_INPROGRESS:
> PreventInTransactionBlock, IsInTransactionBlock. Some statements (VACUUM=
,
> DISCARD ALL) use those functions to  prevent their execution in a multi
> statement context, but those can be escaped using the extended protocol.

Hmmm ... I think this is a duplicate of a bug that we just fixed last
week.  Please see

https://www.postgresql.org/message-id/flat/17434-d9f7a064ce2a88a3%40postgr=
esql.org

https://git.postgresql.org/gitweb/?p=3Dpostgresql.git&a=3Dcommitdiff&h=3Df=
92944137

and let us know (preferably on that thread) if you think there's
still more to do.

			regards, tom lane