Re: BUG #17434: CREATE/DROP DATABASE can be executed in the same transaction with other commands
От | Peter Eisentraut |
---|---|
Тема | Re: BUG #17434: CREATE/DROP DATABASE can be executed in the same transaction with other commands |
Дата | |
Msg-id | 65a899dd-aebc-f667-1d0a-abb89ff3abf8@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: BUG #17434: CREATE/DROP DATABASE can be executed in the same transaction with other commands (Yugo NAGATA <nagata@sraoss.co.jp>) |
Список | pgsql-hackers |
On 08.08.22 17:21, Yugo NAGATA wrote: >>> In fact, the result of IsInTransactionBlock does not make senses at >>> all in pipe-line mode regardless to the fix. ANALYZE could commit all >>> previous commands in pipelining, and this may not be user expected >>> behaviour. >> This seems pretty much isomorphic to the fact that CREATE DATABASE >> will commit preceding steps in the pipeline. > I am not sure if we can think CREATE DATABASE case and ANLALYZE case > similarly. First, CREATE DATABASE is one of the commands that cannot be > executed inside a transaction block, but ANALYZE can be. So, users would > not be able to know ANALYZE in a pipeline causes a commit from the > documentation. Second, ANALYZE issues a commit internally in an early > stage not only after it finished successfully. For example, even if > ANALYZE is failing because a not-existing column name is specified, it > issues a commit before checking the column name. This makes more hard > to know which statements will be committed and which statements not > committed in a pipeline. Also, as you know, there are other commands > that issue internal commits. This has broken the following use: parse: create temporary table t1 (a int) on commit drop bind execute parse: analyze t1 bind execute parse: select * from t1 bind execute sync I think the behavior of IsInTransactionBlock() needs to be further refined to support this. If we are worried about external callers, maybe we need to provide a separate version. AFAICT, all the callers of IsInTransactionBlock() over time have been in vacuum/analyze-related code, so perhaps in master we should just move it there.
В списке pgsql-hackers по дате отправления: