RE: Statement-level rollback
От | Tsunakawa, Takayuki |
---|---|
Тема | RE: Statement-level rollback |
Дата | |
Msg-id | 0A3221C70F24FB45833433255569204D1FB3C1BA@G01JPEXMBYT05 обсуждение исходный текст |
Ответ на | Re: Statement-level rollback (Andres Freund <andres@anarazel.de>) |
Список | pgsql-hackers |
From: Andres Freund [mailto:andres@anarazel.de] > Isn't the realistic scenario for migrations that people will turn this > feature on on a more global basis? If they need to do per transaction choices, > that makes this much less useful for easy migrations. Agreed. My approach of per transaction choice may be overkill. Actually, I didn't think per-transaction change was reallynecessary in practice. But I didn't think of any reason to prohibit per transaction change, so I just wanted to allowflexibility. I think per database/user change (ALTER DATABASE/USER) can be useful, in cases where applications are migrated from otherDBMSs to a PostgreSQL instance. That is, database consolidation for easier data analytics and database management. One database/schema holds data for a PostgreSQL application, and another one stores data for a migrated application. Or, should we recommend a separate PostgreSQL instance on a different VM or container, and just introduce the parameter onlyin postgresql.conf? Regards Takayuki Tsunakawa
В списке pgsql-hackers по дате отправления: