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

Поиск
Список
Период
Сортировка
От PG Bug reporting form
Тема BUG #17565: Extended query protocol incorrectly sets TBLOCK_STARTED even though multiple queries can be executed
Дата
Msg-id 17565-156f3bd8f262150f@postgresql.org
обсуждение исходный текст
Ответы Re: BUG #17565: Extended query protocol incorrectly sets TBLOCK_STARTED even though multiple queries can be executed  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-bugs
The following bug has been logged on the website:

Bug reference:      17565
Logged by:          Matt Jibson
Email address:      matt.jibson@gmail.com
PostgreSQL version: 14.4
Operating system:   linux
Description:

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.

The protocol docs have an excellent section on how to handle multiple
statements in a simple query. Assuming that this is indeed a bug and is
fixed somehow, the extended protocol may need its docs changed to similarly
describe what happens in this case.


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

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