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 по дате отправления: