From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Andreas Karlsson <andreas(at)proxel(dot)se> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Parallel safety tagging of extension functions |
Date: | 2016-05-25 00:41:07 |
Message-ID: | CA+TgmoYedOhLO5pDrYDQMGXFB+JLh8djYRKvbnKJuiDnSUAHOA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, May 19, 2016 at 5:50 PM, Andreas Karlsson <andreas(at)proxel(dot)se> wrote:
> - How should we modify the aggregate functions when upgrading extensions?
> ALTER AGGREGATE cannot change COMBINEFUNC or PARALLEL. My current patch
> updates the system catalogs directly, which should be safe in this case, but
> is this an acceptable solution?
I'd rather extend see us ALTER AGGREGATE to do this.
> - Do you think we should add PARALLEL UNSAFE to the functions which we know
> are unsafe to make it obvious that it is intentional?
That seems likely unnecessary churn from here.
> - I have not added the parallel tags to the functions used by our procedural
> languages. Should we do so?
I don't think that accomplishes anything.
> - I have marked uuid-ossp, chkpass_in() and pgcrypto functions which
> generate random data as safe, despite that they depend on state in the
> backend. My reasoning is that, especially for the pgcrypto functions, that
> nobody should not rely on the PRNG state. For uuid-ossp I am on the fence.
random() is marked parallel-restricted because of setseed(). If
there's no equivalent for other random number generators then I think
they can be construed as safe.
> - I have touched a lot of legacy libraries, like tsearch2 and the spi/*
> stuff. Is that a good idea?
I don't know. It doesn't seem particularly important, but I can't
immediately see a reason not to do it either. You could argue it
might allow for better test coverage...
> - I decided to ignore that isn_weak() exists (and would make all input
> functions PARALLEL RESTRICTED) since it is only there is ISN_WEAK_MODE is
> defined. Is that ok?
That seems fine.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2016-05-25 00:45:51 | Re: Is the unfair lwlock behavior intended? |
Previous Message | Robert Haas | 2016-05-25 00:36:42 | Re: Parallel safety tagging of extension functions |