mirror of
https://github.com/postgres/postgres.git
synced 2025-09-02 04:21:28 +03:00
Allow "internal" subtransactions in parallel mode.
Allow use of BeginInternalSubTransaction() in parallel mode, so long as the subtransaction doesn't attempt to acquire an XID or increment the command counter. Given those restrictions, the other parallel processes don't need to know about the subtransaction at all, so this should be safe. The benefit is that it allows subtransactions intended for error recovery, such as pl/pgsql exception blocks, to be used in PARALLEL SAFE functions. Another reason for doing this is that the API of BeginInternalSubTransaction() doesn't allow reporting failure. pl/python for one, and perhaps other PLs, copes very poorly with an error longjmp out of BeginInternalSubTransaction(). The headline feature of this patch removes the only easily-triggerable failure case within that function. There remain some resource-exhaustion and similar cases, which we now deal with by promoting them to FATAL errors, so that callers need not try to clean up. (It is likely that such errors would leave us with corrupted transaction state inside xact.c, making recovery difficult if not impossible anyway.) Although this work started because of a report of a pl/python crash, we're not going to do anything about that in the back branches. Back-patching this particular fix is obviously not very wise. While we could contemplate some narrower band-aid, pl/python is already an untrusted language, so it seems okay to classify this as a "so don't do that" case. Patch by me, per report from Hao Zhang. Thanks to Robert Haas for review. Discussion: https://postgr.es/m/CALY6Dr-2yLVeVPhNMhuBnRgOZo1UjoTETgtKBx1B2gUi8yy+3g@mail.gmail.com
This commit is contained in:
@@ -545,10 +545,10 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Functions and aggregates must be marked <literal>PARALLEL UNSAFE</literal> if
|
||||
they write to the database, access sequences, change the transaction state
|
||||
even temporarily (e.g., a PL/pgSQL function that establishes an
|
||||
<literal>EXCEPTION</literal> block to catch errors), or make persistent changes to
|
||||
Functions and aggregates must be marked <literal>PARALLEL UNSAFE</literal>
|
||||
if they write to the database, change the transaction state (other than by
|
||||
using a subtransaction for error recovery), access sequences, or make
|
||||
persistent changes to
|
||||
settings. Similarly, functions must be marked <literal>PARALLEL
|
||||
RESTRICTED</literal> if they access temporary tables, client connection state,
|
||||
cursors, prepared statements, or miscellaneous backend-local state that
|
||||
|
Reference in New Issue
Block a user