Re: Parallel safety tagging of extension functions

On 06/14/2016 07:51 PM, Robert Haas wrote:
> On Tue, Jun 14, 2016 at 6:37 AM, Andreas Karlsson <andreas@proxel.se> wrote:
>> I have rebased all my patches on the current master now (and skipped the
>> extensions I previously listed).
>
> Thanks, this is really helpful.  It was starting to get hard to keep
> track of what hadn't been applied yet.  I decided to prioritize
> getting committed the patches where the extension version had already
> been bumped by 749a787c5b25ae33b3d4da0ef12aa05214aa73c7, so I've now
> committed the patches for cube, hstore, intarray, ltree, pg_trgm, and
> seg.  However, in pg_trgm, I changed some of the functions that you
> had marked as PARALLEL RESTRICTED to be PARALLEL SAFE, because I
> didn't see any reason why they needed to be PARALLEL RESTRICTED.  It's
> OK for a parallel-safe function to depend on GUC values, because those
> are synchronized from the leader to all worker processes.  Random
> global variables won't necessarily be kept in sync, but anything
> controlled by the GUC mechanism will be.  If there's some other reason
> you think those functions aren't parallel-safe, please let me know.

Nah, this is a leftover from before I realized that GUCs are safe. I 
thought I went through all the code and fixed this misunderstanding. 
Thanks for spotting this.

> I'm still in favor of rejecting the adminpack patch.  To me, that just
> seems like attaching a larger magazine to the gun pointed at your
> foot.  I can't deny that in a strict sense those functions are
> parallel-safe, but I think they are better left alone.

Making them parallel restricted should prevent them from being a 
footgun, but I also do not see any huge benefit from doing so (while 
making them safe seems dangerous). I do not care either way.

Andreas