Re: pg_promote not marked as parallel-restricted in pg_proc.dat - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: pg_promote not marked as parallel-restricted in pg_proc.dat
Date
Msg-id 20181029224755.GA1644@paquier.xyz
Whole thread Raw
In response to Re: pg_promote not marked as parallel-restricted in pg_proc.dat  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pg_promote not marked as parallel-restricted in pg_proc.dat  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Mon, Oct 29, 2018 at 10:08:45AM -0400, Tom Lane wrote:
> Laurenz Albe <laurenz.albe@cybertec.at> writes:
> I'd vote for PARALLEL UNSAFE myself.  Otherwise you have to ask questions
> about whether it's really safe to do this while parallel workers are doing
> things.  Perhaps the answer is "yes", but what's the point of having to
> verify that?

All the backup-related functions doing on-disk activity are marked as
parallel-restricted:
=# select proparallel, proname from pg_proc where proname ~ 'backup';
 proparallel |       proname
-------------+----------------------
 s           | pg_is_in_backup
 s           | pg_backup_start_time
 r           | pg_stop_backup
 r           | pg_start_backup
 r           | pg_stop_backup
(5 rows)

As restricted, only the group leader is allowed to execute the
function.  So as long as we enforce the execution uniqueness, I don't
think that there is any point in enforcing a serial scan for the whole
query.  Queries launching pg_promote are unlikely going to be much
complicated, still it does not seem a consistent experience to me to not
use the same level for such operations.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: replication_slots usability issue
Next
From: Corey Huinker
Date:
Subject: Re: date_trunc() in a specific time zone