pg.ddx.io  pgsql-bugs@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
To: Yugo NAGATA <nagata@sraoss.co.jp>
To: Tom Lane <tgl@sss.pgh.pa.us>
To: pgsql-hackers@postgresql.org
Cc: David G. Johnston <david.g.johnston@gmail.com>
Cc: Bruce Momjian <bruce@momjian.us>
Cc: PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Subject: Re: BUG #17434: CREATE/DROP DATABASE can be executed in the same transaction with other commands
Date: Wed, 9 Nov 2022 17:24:43 +0100
Message-ID: <65a899dd-aebc-f667-1d0a-abb89ff3abf8@enterprisedb.com> (raw)
In-Reply-To: <20220809002102.b815cd4dad20fdc91dff5ce8@sraoss.co.jp>
References: <17434-d9f7a064ce2a88a3@postgresql.org>
	<YtCrjN0HLew0w4Ss@momjian.us>
	<3190751.1657845414@sss.pgh.pa.us>
	<CAKFQuwbY_vJWcvJLUz2r+zzwwhkJbjzjojfGx=Mvd9TZ0TTKew@mail.gmail.com>
	<3498921.1657919211@sss.pgh.pa.us>
	<CAKFQuwa9JQgKgg3Djrx=7p1Phhj68QEq0TWYG72Xv-nPz61r0w@mail.gmail.com>
	<805866.1658175624@sss.pgh.pa.us>
	<CAKFQuwYQpm6E4nTgiOZAGRg0JKquHaXQ0JkqruWeHuOQX6-70g@mail.gmail.com>
	<2350990.1658848101@sss.pgh.pa.us>
	<CAKFQuwYRYhF8iOD9MHp7VuZur_JvVEjDzpMHuUHNeYReB5v2Sw@mail.gmail.com>
	<2356216.1658849834@sss.pgh.pa.us>
	<CAKFQuwYxPhPVMGJ-uoV7rq291xAU3dwww2fWwMuaz6EPiruJ5g@mail.gmail.com>
	<2361330.1658851386@sss.pgh.pa.us>
	<CAKFQuwYaN+SJyHcXyjAwZ7zRCze+6Xj7ns_hOEg2+fhZEJUOHg@mail.gmail.com>
	<2363212.1658852059@sss.pgh.pa.us>
	<20220728105134.d5ce51dd756b3149e9b9c52c@sraoss.co.jp>
	<3214515.1658976655@sss.pgh.pa.us>
	<20220809002102.b815cd4dad20fdc91dff5ce8@sraoss.co.jp>

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.






view thread (35+ messages)  latest in thread

Message-ID: <65a899dd-aebc-f667-1d0a-abb89ff3abf8@enterprisedb.com>
Permalink:  ../65a899dd-aebc-f667-1d0a-abb89ff3abf8@enterprisedb.com/
Also on:    postgresql.org/message-id/65a899dd-aebc-f667-1d0a-abb89ff3abf8@enterprisedb.com

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-bugs@postgresql.org
  Cc: peter.eisentraut@enterprisedb.com, nagata@sraoss.co.jp, tgl@sss.pgh.pa.us, pgsql-hackers@postgresql.org, david.g.johnston@gmail.com, bruce@momjian.us, pgsql-bugs@lists.postgresql.org
  Subject: Re: BUG #17434: CREATE/DROP DATABASE can be executed in the same transaction with other commands
  In-Reply-To: <65a899dd-aebc-f667-1d0a-abb89ff3abf8@enterprisedb.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox