cannot start commands during a parallel operation

Justin Pryzby pryzby at telsasoft.com
Tue Aug 13 07:02:28 PDT 2024


On Mon, Aug 12, 2024 at 10:48:29AM -0400, Robert Haas wrote:
> On Mon, Aug 12, 2024 at 10:11 AM Justin Pryzby <pryzby at telsasoft.com> wrote:
> > Hm, maybe I'm being dense, but I can't see what it's doing that would
> > make it unsafe.
> >
> > https://www.postgresql.org/docs/16/parallel-safety.html
> > | 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 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 the system cannot synchronize
> > | across workers. For example, setseed and random are parallel restricted
> > | for this last reason.
> 
> CommandCounterIncrement() is an example of changing the transaction state.

Okay but .. look at this from the perspective of a user.  How am I
supposed to know whether a function will invoke CCI ?  How am I supposed
to know if I can mark a function as parallel safe?

If someone were to ask me what it means to "change transaction state", I
would've said it means issuing begin/commit/rollback, but maybe you're
telling me that any sql command will do so, and any pl/pgsql functions
which includes sql commands must be marked parallel restricted?  If so,
I would've expected the documentation to say so directly.

I'm happy to submit a documentation patch, once I myself understand, if
that's what's needed.

-- 
Justin


More information about the postgis-devel mailing list