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.
