On 06/14/2016 07:51 PM, Robert Haas wrote:
On Tue, Jun 14, 2016 at 6:37 AM, Andreas Karlsson <andr...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
