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
