From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Postgres hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_promote not marked as parallel-restricted in pg_proc.dat |
Date: | 2018-10-29 22:47:55 |
Message-ID: | 20181029224755.GA1644@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Oct 29, 2018 at 10:08:45AM -0400, Tom Lane wrote:
> Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Corey Huinker | 2018-10-29 23:04:10 | Re: date_trunc() in a specific time zone |
Previous Message | Joshua D. Drake | 2018-10-29 22:13:07 | Re: replication_slots usability issue |