From 0075d78947e3800c5a807f48fd901f16db91101b Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Thu, 28 Mar 2024 12:43:10 -0400 Subject: 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 --- doc/src/sgml/parallel.sgml | 8 ++++---- doc/src/sgml/ref/create_function.sgml | 20 +++++++++++--------- 2 files changed, 15 insertions(+), 13 deletions(-) (limited to 'doc/src') diff --git a/doc/src/sgml/parallel.sgml b/doc/src/sgml/parallel.sgml index 5acc9537d6f..dae9dd7f2f9 100644 --- a/doc/src/sgml/parallel.sgml +++ b/doc/src/sgml/parallel.sgml @@ -545,10 +545,10 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%'; - Functions and aggregates must be marked PARALLEL UNSAFE if - they write to the database, access sequences, change the transaction state - even temporarily (e.g., a PL/pgSQL function that establishes an - EXCEPTION block to catch errors), or make persistent changes to + Functions and aggregates must be marked PARALLEL UNSAFE + 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 PARALLEL RESTRICTED if they access temporary tables, client connection state, cursors, prepared statements, or miscellaneous backend-local state that diff --git a/doc/src/sgml/ref/create_function.sgml b/doc/src/sgml/ref/create_function.sgml index 863d99d1fc0..0d240484cd3 100644 --- a/doc/src/sgml/ref/create_function.sgml +++ b/doc/src/sgml/ref/create_function.sgml @@ -428,22 +428,24 @@ CREATE [ OR REPLACE ] FUNCTION PARALLEL - PARALLEL UNSAFE indicates that the function - can't be executed in parallel mode and the presence of such a + + PARALLEL UNSAFE indicates that the function + can't be executed in parallel mode; the presence of such a function in an SQL statement forces a serial execution plan. This is the default. PARALLEL RESTRICTED indicates that - the function can be executed in parallel mode, but the execution is - restricted to parallel group leader. PARALLEL SAFE + the function can be executed in parallel mode, but only in the parallel + group leader process. PARALLEL SAFE indicates that the function is safe to run in parallel mode without - restriction. + restriction, including in parallel worker processes. Functions should be labeled parallel unsafe if they modify any database - state, or if they make changes to the transaction such as using - sub-transactions, or if they access sequences or attempt to make - persistent changes to settings (e.g., setval). They should - be labeled as parallel restricted if they access temporary tables, + state, change the transaction state (other than by using a + subtransaction for error recovery), access sequences (e.g., by + calling currval) or make persistent changes to + settings. They should + be labeled parallel restricted if they access temporary tables, client connection state, cursors, prepared statements, or miscellaneous backend-local state which the system cannot synchronize in parallel mode (e.g., setseed cannot be executed other than by the group -- cgit v1.2.3