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.
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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company