Re: group locking: incomplete patch, just for discussion

On Fri, Oct 31, 2014 at 11:02 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> You mentioned earlier that functions would need to be marked proisparallel etc..
>
> What conditions will that be protecting against? If we aren't going to
> support the general case where every single thing works, can we at
> least discuss what the list of cases is that we will support.

In general, any operation that relies on backend-private state not
shared with a cooperating backend isn't parallel-safe.  For example,
consider:

SELECT setseed(1);
SELECT random() FROM generate_series(1,1000) g;

This sequence of queries can be relied upon to produce the same output
every time.  But if some of the random() calls are executed in another
backend, you'll get different results because random() works by using
backend-private memory to store its pseudo-random state.  It's
unlikely to be worth the effort to move the pseudo-random state to a
DSM for parallelism, so we probably just want to disallow parallel
query when random() is in use, or, better still, disallow
parallelizing only the particular query node that uses random().

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company