On Thu, Nov 13, 2014 at 7:27 PM, Simon Riggs <si...@2ndquadrant.com> wrote: > On 12 November 2014 00:54, Robert Haas <robertmh...@gmail.com> wrote: >> On Tue, Nov 11, 2014 at 3:29 AM, Simon Riggs <si...@2ndquadrant.com> wrote: >>> * only functions marked as "CONTAINS NO SQL" >>> We don't really know what proisparallel is, but we do know what >>> CONTAINS NO SQL means and can easily check for it. >>> Plus I already have a patch for this, slightly bitrotted. >> >> Interestingly, I have a fairly solid idea of what proisparallel is, >> but I have no clear idea what CONTAINS NO SQL is or why it's relevant. >> I would imagine that srandom() contains no SQL under any reasonable >> definition of what that means, but it ain't parallel-safe. > > What is wrong in generating random numbers in parallel?
If they're random, nothing, provide that you use a different seed in each backend. But if the seed has been set using srandom(), then we must generate the particular sequence of random numbers associated with that seed. If we don't, the behavior is incompatible with what happens apart from parallel mode. > But I'm sure many volatile functions would be annoying to support, so > CONTAINS NO SQL and STABLE/IMMUTABLE seems OK for the first thing. It might be OK to assume that immutable functions are fine, but not all stable functions look like they'll be safe, or not without additional effort: e.g. inet_client_addr(), pg_backend_pid(), pg_cursor(), pg_event_trigger_dropped_objects(). Or even, more mundanely, generate_series(), unless we ensure all calls are in the same backend. On the other hand, there are quite a few stable functions that it seems like we would want to allow in parallel queries, like to_char(), concat(), and textanycat(). I still don't know what CONTAINS NO SQL means. -- 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