Re: [GENERAL] Slow PITR restore
От | Markus Schiltknecht |
---|---|
Тема | Re: [GENERAL] Slow PITR restore |
Дата | |
Msg-id | 4762822D.5010408@bluegap.ch обсуждение исходный текст |
Ответ на | Re: [GENERAL] Slow PITR restore (Hannu Krosing <hannu@skype.net>) |
Список | pgsql-hackers |
Hello Hannu, Hannu Krosing wrote: >> (For parallelized queries, superuser privileges might appear wrong, but >> I'm arguing that parallelizing the rights checking isn't worth the >> trouble, so the initiating worker backend should do that and only >> delegate safe jobs to hepler backends. Or is that a serious limitation >> in a way?) > > at least functions defined with SECURITY DEFINER; may be a problem Uhm.. what I had in mind was parallelizing seqential scans, index scans, joins and such - database internal stuff. Parallelizing user defined functions (or what did you have in mind?) is more difficult and sometimes impossible, because the planner cannot know ahead, what the function's going to do. However, thinking about it, maybe, one could and should try to parallelize computationally intensive IMMUTABLE functions. But already with STABLE ones I'm getting suspicious. It would require users to write real thread-safe (well, multi-process-safe) functions, which I doubt somewhat. Granted, they theoretically *should* be safe, but... Anyway, if that's the only show stopper, one could certainly tell helper backends to substitute their superuser privileges with the invoker's privileges. Not sure if that's worth the trouble, though. Regards Markus
В списке pgsql-hackers по дате отправления: