On Thu, Nov 13, 2014 at 7:27 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On 12 November 2014 00:54, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Tue, Nov 11, 2014 at 3:29 AM, Simon Riggs <simon@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