Re: pg_promote not marked as parallel-restricted in pg_proc.dat
От | Michael Paquier |
---|---|
Тема | Re: pg_promote not marked as parallel-restricted in pg_proc.dat |
Дата | |
Msg-id | 20181029224755.GA1644@paquier.xyz обсуждение исходный текст |
Ответ на | Re: pg_promote not marked as parallel-restricted in pg_proc.dat (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pg_promote not marked as parallel-restricted in pg_proc.dat
|
Список | 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
Вложения
В списке pgsql-hackers по дате отправления: