Re: pg_promote not marked as parallel-restricted in pg_proc.dat

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: pg_promote not marked as parallel-restricted in pg_proc.dat
Дата
Msg-id CA+Tgmoac92Psb=2siSrEghVJfv6DFZTdOEoq9beTjUHkZ53jgw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pg_promote not marked as parallel-restricted in pg_proc.dat  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: pg_promote not marked as parallel-restricted in pg_proc.dat
Список pgsql-hackers
On Mon, Oct 29, 2018 at 6:48 PM Michael Paquier <michael@paquier.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: pg_dumpall --exclude-database option
Следующее
От: Robert Haas
Дата:
Сообщение: Re: FETCH FIRST clause WITH TIES option