Re: [GENERAL] Slow PITR restore - Mailing list pgsql-hackers

From Markus Schiltknecht
Subject Re: [GENERAL] Slow PITR restore
Date
Msg-id 4762822D.5010408@bluegap.ch
Whole thread Raw
In response to Re: [GENERAL] Slow PITR restore  (Hannu Krosing <hannu@skype.net>)
List 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 by date:

Previous
From: Hannu Krosing
Date:
Subject: Re: VLDB Features
Next
From: Markus Schiltknecht
Date:
Subject: Re: [GENERAL] Slow PITR restore