Re: Statement-level rollback

On 12/7/18 12:50 PM, Alvaro Herrera wrote:
> On 2018-Dec-07, Robert Haas wrote:
>
>> More generally, whether or not we should "keep something away from our
>> users" really depends on how likely the upsides are to occur relative
>> to the downsides.  We don't try to keep users from running DELETE
>> because they might delete data they want; that would be nanny-ism.
>> But we do try to keep them from reading dirty data from an uncommitted
>> transaction because we can't implement that without a risk of server
>> crashes, and that's too big a downside to justify the upside.  If we
>> could do it safely, we might.
>>
>>  From that point of view, this is doubtless not the worst feature
>> PostgreSQL will ever have, but it sure ain't the best.
> Well, look at this from this point of view: EnterpriseDB implemented
> this because of customer demand (presumably).  Fujitsu also implemented
> this for customers.  The pgjdbc driver implemented this for its users.
> Now 2ndQuadrant also implemented this, and not out of the goodness of
> our hearts.  Is there any room to say that there is no customer demand
> for this feature?

Amazon also implemented something similar for the database migration 
tool. I am unsure if they do it similarly with the DMS. With the DMT it 
definitely had the XID issue that some are concerned with but I would 
argue that is the cost of doing business.

JD


>

-- 
Command Prompt, Inc. || http://the.postgres.company/ || @cmdpromptinc
***  A fault and talent of mine is to tell it exactly how it is.  ***
PostgreSQL centered full stack support, consulting and development.
Advocate: @amplifypostgres || Learn: https://postgresconf.org
*****     Unless otherwise stated, opinions are my own.   *****