On Fri, Oct 31, 2014 at 11:02 AM, Simon Riggs <si...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
