Re: [HACKERS] Statement-level rollback - Mailing list pgsql-hackers

On 2 November 2017 at 01:33, Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:

> The proposed statement-level rollback feature works in a slightly
> different context.  It does not change when or how a transaction or
> transaction block begins and ends.  It only changes what happens inside
> explicit transaction blocks.

Yes, this is not the same thing as autocommit. There should be no
concerns there.

> The difference is how error recovery works.

Yes

> So this will necessarily be
> tied to how the client code or other surrounding code is structured or
> what the driver or framework is doing in the background to manage
> transactions.  It would also be bad if client code was not prepared for
> this new behavior, reported the transaction as complete while some
> commands in the middle were omitted.

This new feature allows a simplified development style because earlier
statements don't need to be re-executed, nor do we have to manually
wrap everything in savepoints.

It changes the assumptions of error recovery, so this will break code
already written for PostgreSQL. The purpose is to allow new code to be
written using the easier style.

Compare this with SERIALIZABLE mode - no need for time consuming
additional coding.

> Drivers can already achieve this behavior and do do that by issuing
> savepoint commands internally.  The point raised in this thread was that
> that creates too much network overhead, so a backend-based solution
> would be preferable.  We haven't seen any numbers or other evidence to
> quantify that claim, so maybe it's worth looking into that some more.
>
> In principle, a backend-based solution that drivers just have to opt
> into would save a lot of duplication.  But the drivers that care or
> require it according to their standards presumably already implement
> this behavior in some other way, so it comes back to whether there is a
> performance or other efficiency gain here.
>
> Another argument was that other SQL implementations have this behavior.
> This appears to be the case.  But as far as I can tell, it is also tied
> to their particular interfaces and the structure and flow control they
> provide.  So a client-side solution like psql already provides or
> something in the various drivers would work just fine here.
>
> So my summary for the moment is that a GUC or similar run-time setting
> might be fine, with appropriate explanation and warnings.  But it's not
> clear whether it's worth it given the existing alternatives.

This is about simplicity for the developer, not so much about performance.

A backend-based solution is required for PL procedures and functions.

We could put this as an option into PL/pgSQL, but it seems like it is
a function of the transaction manager rather than the driver.

-- 
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers