On 31 October 2014 18:47, Robert Haas <robertmh...@gmail.com> wrote: > 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,
Yes, the principle is easy to understand, but that was not the question. You are saying that placing restrictions on which functions can execute is necessary, yet at the same time saying that we must have generalised locking for workers because restrictions on locking are not acceptable. I don't point that out because I want an argument or to prove a point, but because there are important things on the table here. What are the specific restrictions you are suggesting we place on parallel workers? We need that definition clear so we can decide how to mark the functions. If we don't know, which is easily understandable, then the best way to find that out is to build a restricted solution and to expand slowly outwards to find problems. An obvious milestone there is whether a function contains SQL, which is the point chosen by some other databases. I personally hope to expand upon that, but it would be useful to reach it first and then continue from there. I was already thinking of implementing CONTAINS NO SQL as a SQL Standard function marking since it can be used to optimize COPY further. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
