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

Предыдущее
От: Hannu Krosing
Дата:
Сообщение: Re: VLDB Features
Следующее
От: Markus Schiltknecht
Дата:
Сообщение: Re: [GENERAL] Slow PITR restore