From: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
---|---|
To: | Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Cc: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: BUG #17434: CREATE/DROP DATABASE can be executed in the same transaction with other commands |
Date: | 2022-11-09 16:24:43 |
Message-ID: | 65a899dd-aebc-f667-1d0a-abb89ff3abf8@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2022-11-09 16:38:05 | Re: BUG #17434: CREATE/DROP DATABASE can be executed in the same transaction with other commands |
Previous Message | Tom Lane | 2022-11-09 16:17:29 | Re: BUG #17434: CREATE/DROP DATABASE can be executed in the same transaction with other commands |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2022-11-09 16:38:05 | Re: BUG #17434: CREATE/DROP DATABASE can be executed in the same transaction with other commands |
Previous Message | Tom Lane | 2022-11-09 16:17:29 | Re: BUG #17434: CREATE/DROP DATABASE can be executed in the same transaction with other commands |