Re: BUG #17565: Extended query protocol incorrectly sets TBLOCK_STARTED even though multiple queries can be executed

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #17565: Extended query protocol incorrectly sets TBLOCK_STARTED even though multiple queries can be executed
Дата
Msg-id 2185026.1659392478@sss.pgh.pa.us
обсуждение исходный текст
Ответ на BUG #17565: Extended query protocol incorrectly sets TBLOCK_STARTED even though multiple queries can be executed  (PG Bug reporting form <noreply@postgresql.org>)
Список pgsql-bugs
PG Bug reporting form <noreply@postgresql.org> writes:
> The extended query protocol is most often used with the 4 messages in the
> sequence: Parse, Bind, Execute, Sync. Parse, Bind, and Execute all call
> start_xact_command, which will change blockState to TBLOCK_STARTED. However
> it is within the protocol spec to instead do: Parse, Bind, Execute, Parse,
> 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 transaction",
> 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%40postgresql.org

https://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=f92944137

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

            regards, tom lane



В списке pgsql-bugs по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: BUG #17564: Planner bug in combination of generate_series(), unnest() and ORDER BY
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Statistics updates is delayed when using `commit and chain`