Re: BUG #17434: CREATE/DROP DATABASE can be executed in the same transaction with other commands
От | Tom Lane |
---|---|
Тема | Re: BUG #17434: CREATE/DROP DATABASE can be executed in the same transaction with other commands |
Дата | |
Msg-id | 2356216.1658849834@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #17434: CREATE/DROP DATABASE can be executed in the same transaction with other commands ("David G. Johnston" <david.g.johnston@gmail.com>) |
Ответы |
Re: BUG #17434: CREATE/DROP DATABASE can be executed in the same transaction with other commands
|
Список | pgsql-bugs |
"David G. Johnston" <david.g.johnston@gmail.com> writes: > Thanks! This added section is clear and now affirms the understanding I've > come to with this thread, mostly. I'm still of the opinion that the > definition of "cannot be executed inside a transaction block" means that we > must "auto-sync" (implicit commit) before and after the restricted command, > not just after, and that the new section should cover this - whether we do > or do not - explicitly. I'm not excited about your proposal to auto-commit before starting the command. In the first place, we can't: we do not know whether the command will call PreventInTransactionBlock. Restructuring to change that seems untenable in view of past cowboy decisions about use of PreventInTransactionBlock in the replication logic. In the second place, it'd be a deviation from the current behavior (namely that a failure in CREATE DATABASE et al rolls back previous un-synced commands) that is not necessary to fix a bug, so changing that in the back branches would be a hard sell. I don't even agree that it's obviously better than the current behavior, so I'm not much on board with changing it in HEAD either. regards, tom lane
В списке pgsql-bugs по дате отправления: