Greetings,
* Andres Freund (andres@anarazel.de) wrote:
> On 2018-11-27 00:47:47 +0100, Vik Fearing wrote:
> > On 27/11/2018 00:39, Andres Freund wrote:
> > > On 2018-11-27 00:33:10 +0100, Vik Fearing wrote:
> > >> On 26/11/2018 22:23, Gajus Kuizinas wrote:
> > >>> I was wondering what is the reason IMMUTABLE functions are not by
> > >>> default PARALLEL SAFE and if the default behaviour could be changed to
> > >>> make IMMUTABLE functions PARALLEL SAFE?
> > >>
> > >> I think I have to concur with this. When is an immutable function not
> > >> parallel safe?
> > >>
> > >> Sure it could be mislabeled as immutable but it could just as easily be
> > >> mislabeled as parallel safe. And we already treat fake immutable
> > >> functions as user errors, for example in indexes.
> > >
> > > I think it'd introduce more problems than it'd solve. Either you ignore
> > > the proparallel setting - resulting in broken catalog querying - or you
> > > have to have a decent amount of special behaviour that an explicit ALTER
> > > FUNCTION ... IMMUTABLE | STABLE | VOLATILE and SET PARALLEL { UNSAFE
> > > | RESTRICTED | SAFE } would also need to change the respective other
> > > category.
> >
> > Surely a simple rule could be made that provolatile='i' trumps
> > proparallel. No need to make them agree.
> >
> > The default catalogs should agree (and I would expect the sanity checks
> > to look for that) but here we're talking about user functions.
>
> I think it'd be entirely unacceptable that
> SELECT * FROM pg_proc WHERE proparallel = 's'
> wouldn't actually return all the functions that are parallel safe.
Agreed, but I could see us having a regression test which complains if
it finds any which are marked as immutable but aren't parallel safe.
That said, I do *not* think we should make any assumptions here- users
incorrectly mark things all the time but we shouldn't encourage that and
we shouldn't assume that functions marked as immutable are parallel
safe.
Thanks!
Stephen