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. 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers