From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_promote not marked as parallel-restricted in pg_proc.dat |
Date: | 2018-10-31 17:09:53 |
Message-ID: | CA+Tgmoac92Psb=2siSrEghVJfv6DFZTdOEoq9beTjUHkZ53jgw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Oct 29, 2018 at 6:48 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> 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.
There's no rule whatsoever that a parallel worker can't write to the
disk. pg_start_backup and pg_stop_backup have to be
parallel-restricted because, when used in non-exclusive mode, they
establish backend-local state that wouldn't be synchronized with the
state in the workers -- namely the information that a non-exclusive
backup is in progress.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2018-10-31 17:17:39 | Re: FETCH FIRST clause WITH TIES option |
Previous Message | Andrew Dunstan | 2018-10-31 17:04:02 | Re: pg_dumpall --exclude-database option |