From: | "MauMau" <maumau307(at)gmail(dot)com> |
---|---|
To: | "Alvaro Herrera" <alvherre(at)2ndquadrant(dot)com>, "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> |
Cc: | "'Simon Riggs'" <simon(at)2ndquadrant(dot)com>, "Peter Eisentraut" <peter(dot)eisentraut(at)2ndquadrant(dot)com>, "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] Statement-level rollback |
Date: | 2018-06-16 01:42:39 |
Message-ID: | A8377C6A188B4130A27E69851BF026BF@tunaPC |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-jdbc |
From: Alvaro Herrera
> I've been looking at re-implementing this feature recently, using
> Tsunakawa's proposed UI of a GUC transaction_rollback_scope that can
> take values "transaction" (default, current behavior) and
"statement".
> I didn't take other parts of his patch though; see below.
Thank you so much for reviving this thread!
> I propose that we solve this by
> allowing this feature to be enabled only via one of:
>
> * a PGOPTIONS connection-time option
> * ALTER USER SET (transaction_rollback_scope)
Why don't we also allow ALTER DATABASE SET for a database exclusively
for data migrated from another DBMS?
> but it can be *disabled* normally via SET. In other words, changing
the
> scope from transaction to statement in a running session is
forbidden,
> but changing it the other way around is allowed (if app is unsure
> whether env is unsafe, it can set the scope to "transaction" to
ensure
> it's safe from that point onwards). Changing the scope in
> postgresql.conf is forbidden, so a server is never unsafe as a
whole.
Would it be dangerous to allow both enabling and disabling the
statement-level rollback only outside a transaction block? I thought
it was considered dangerous to change the setting inside a transaction
block.
> Drivers such as JDBC can easily use this mode, for example a
connection
> option such as "AUTOSAVE=SERVER" can automatically add the
> transaction_rollback_scope option. (Naturally, if the server does
not
> support transaction_rollback_scope and the user gave that option,
this
> causes an exception to be raised -- NOT to fallback to the standard
> transaction behavior!)
How do the drivers know, from the server error response to connection
request, that transaction_rollback_scope is unsupported?
> Tsunakawa's implementation puts the feature in postgres.c's client
loop.
> I think a better way to implement this is to change xact.c to have a
new
> TBLOCK state which indicates when to start a new internal
> subtransaction; StartTransactionCommand pushes a new element into
the
> transaction stack and puts it in the new state; a subsequent
operation
> actually starts the new subtransaction. (This design decision
allows
> things like SAVEPOINT to work correctly by having the
> subtrasaction-for-savepoint appear *before* the internal
subtransaction,
> so a subsequent "SELECT 0/0" doesn't remove the user declared
> savepoint.)
That sounds interesting.
* How can PLs like PL/pgSQL utilize this to continue upon an SQL
failure? They don't call StartTransactionCommand.
* How can psql make use of this feature for its ON_ERROR_ROLLBACK?
Regards
MauMau
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2018-06-16 03:30:30 | Re: WAL prefetch |
Previous Message | Peter Geoghegan | 2018-06-15 23:46:44 | Re: Making all nbtree entries unique by having heap TIDs participate in comparisons |
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2018-06-16 04:13:35 | Re: [HACKERS] Statement-level rollback |
Previous Message | Alvaro Herrera | 2018-06-15 20:23:28 | Re: [HACKERS] Statement-level rollback |