Re: BUG #17434: CREATE/DROP DATABASE can be executed in the same transaction with other commands

2022-12-13 Thread Tom Lane
I wrote: > Peter Eisentraut writes: >> The case I was working on is the same as Israel's. He has confirmed >> that this fixes the issue we have been working on. > OK, I'll make this happen soon. Pushed. I left out the idea of making this conditional on whether any preceding command had

Re: BUG #17434: CREATE/DROP DATABASE can be executed in the same transaction with other commands

2022-12-12 Thread Tom Lane
Peter Eisentraut writes: > On 25.11.22 18:06, Tom Lane wrote: >> In my mind, this is waiting for Peter to opine on whether it satisfies >> his concern. > The case I was working on is the same as Israel's. He has confirmed > that this fixes the issue we have been working on. OK, I'll make this

Re: BUG #17434: CREATE/DROP DATABASE can be executed in the same transaction with other commands

2022-12-12 Thread Peter Eisentraut
On 25.11.22 18:06, Tom Lane wrote: Israel Barth Rubio writes: It would be great if we can back-patch this to all supported versions, as the issue itself is currently affecting them all. In my mind, this is waiting for Peter to opine on whether it satisfies his concern. The case I was

Re: BUG #17434: CREATE/DROP DATABASE can be executed in the same transaction with other commands

2022-11-25 Thread Tom Lane
Israel Barth Rubio writes: > It would be great if we can back-patch this to all supported versions, > as the issue itself is currently affecting them all. In my mind, this is waiting for Peter to opine on whether it satisfies his concern. I'm also looking for input on whether to reject if

Re: BUG #17434: CREATE/DROP DATABASE can be executed in the same transaction with other commands

2022-11-25 Thread Israel Barth Rubio
> Attached is a draft patch along the lines I speculated about above. > It breaks backwards compatibility in that PreventInTransactionBlock > commands will now be rejected if they're a non-first command in a > pipeline. I think that's okay, and arguably desirable, for HEAD > but I'm pretty

Re: BUG #17434: CREATE/DROP DATABASE can be executed in the same transaction with other commands

2022-11-16 Thread Yugo NAGATA
On Thu, 10 Nov 2022 15:33:37 -0500 Tom Lane wrote: > Yugo NAGATA writes: > > Tom Lane wrote: > >> Hmm. Maybe the right way to think about this is "if we have completed an > >> EXECUTE, and not yet received a following SYNC, then report that we are in > >> a transaction block"? But I'm not

Re: BUG #17434: CREATE/DROP DATABASE can be executed in the same transaction with other commands

2022-11-10 Thread Tom Lane
Yugo NAGATA writes: > Tom Lane wrote: >> Hmm. Maybe the right way to think about this is "if we have completed an >> EXECUTE, and not yet received a following SYNC, then report that we are in >> a transaction block"? But I'm not sure if that breaks any other cases. > Or, in that case,

Re: BUG #17434: CREATE/DROP DATABASE can be executed in the same transaction with other commands

2022-11-09 Thread Yugo NAGATA
On Wed, 09 Nov 2022 11:38:05 -0500 Tom Lane wrote: > Peter Eisentraut writes: > > 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 >

Re: BUG #17434: CREATE/DROP DATABASE can be executed in the same transaction with other commands

2022-11-09 Thread Yugo NAGATA
On Wed, 09 Nov 2022 11:17:29 -0500 Tom Lane wrote: > Yugo NAGATA writes: > > Tom Lane wrote: > >> What do you think of the attached wording? > > > It looks good to me. That describes the expected behaviour exactly. > > Pushed that, then. Thank you. > >> I don't think the pipeline angle is

Re: BUG #17434: CREATE/DROP DATABASE can be executed in the same transaction with other commands

2022-11-09 Thread Peter Eisentraut
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

Re: BUG #17434: CREATE/DROP DATABASE can be executed in the same transaction with other commands

2022-11-09 Thread Tom Lane
Peter Eisentraut writes: > 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 >

Re: BUG #17434: CREATE/DROP DATABASE can be executed in the same transaction with other commands

2022-11-09 Thread Tom Lane
Yugo NAGATA writes: > Tom Lane wrote: >> What do you think of the attached wording? > It looks good to me. That describes the expected behaviour exactly. Pushed that, then. >> I don't think the pipeline angle is of concern to anyone who might be >> reading these comments with the aim of

Re: BUG #17434: CREATE/DROP DATABASE can be executed in the same transaction with other commands

2022-11-09 Thread Yugo NAGATA
On Sun, 06 Nov 2022 12:54:17 -0500 Tom Lane wrote: > Yugo NAGATA writes: > >> The attached patch tries to add comments explaining it on the functions. > > > I forward it to the hackers list because the patch is to fix comments. > > What do you think of the attached wording? It looks good to

Re: BUG #17434: CREATE/DROP DATABASE can be executed in the same transaction with other commands

2022-11-06 Thread Tom Lane
Yugo NAGATA writes: >> The attached patch tries to add comments explaining it on the functions. > I forward it to the hackers list because the patch is to fix comments. What do you think of the attached wording? I don't think the pipeline angle is of concern to anyone who might be reading

Re: BUG #17434: CREATE/DROP DATABASE can be executed in the same transaction with other commands

2022-09-29 Thread Yugo NAGATA
Hi, On Tue, 9 Aug 2022 00:21:02 +0900 Yugo NAGATA wrote: > On Wed, 27 Jul 2022 22:50:55 -0400 > Tom Lane wrote: > > > Yugo NAGATA writes: > > > I've looked at the commited fix. What I wonder is whether a change in > > > IsInTransactionBlock() is necessary or not. > > > > I've not examined