RE: Statement-level rollback - Mailing list pgsql-hackers

From Tsunakawa, Takayuki
Subject RE: Statement-level rollback
Date
Msg-id 0A3221C70F24FB45833433255569204D1FB3C1BA@G01JPEXMBYT05
Whole thread Raw
In response to Re: Statement-level rollback  (Andres Freund <andres@anarazel.de>)
List 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 by date:

Previous
From: "Tsunakawa, Takayuki"
Date:
Subject: RE: Too many logs are written on Windows (LOG: could not reserveshared memory region (addr=%p) for child %p:)
Next
From: "Takahashi, Ryohei"
Date:
Subject: RE: Too many logs are written on Windows (LOG: could not reserveshared memory region (addr=%p) for child %p:)