Functions Immutable but not parallel safe?
There's 11 functions which are marked immutable, but are marked as
parallel unsafe.
postgres=# select proname from pg_proc where provolatile = 'i' and
proparallel = 'u';
proname
-----------------------------
_pg_expandarray
_pg_keysequal
_pg_truetypid
_pg_truetypmod
_pg_char_max_length
_pg_char_octet_length
_pg_numeric_precision
_pg_numeric_precision_radix
_pg_numeric_scale
_pg_datetime_precision
_pg_interval_type
(11 rows)
I'm finding hard to imagine a reason why these might be unsafe, but
failed. I do notice they're all only used in information_schema.
Could it just perhaps be that these just missed the verification
process the other functions went through to determine their parallel
safety?
--
David Rowley 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
On Thu, Nov 24, 2016 at 5:29 AM, David Rowley
<david.rowley@2ndquadrant.com> wrote:
There's 11 functions which are marked immutable, but are marked as
parallel unsafe.postgres=# select proname from pg_proc where provolatile = 'i' and
proparallel = 'u';
proname
-----------------------------
_pg_expandarray
_pg_keysequal
_pg_truetypid
_pg_truetypmod
_pg_char_max_length
_pg_char_octet_length
_pg_numeric_precision
_pg_numeric_precision_radix
_pg_numeric_scale
_pg_datetime_precision
_pg_interval_type
(11 rows)I'm finding hard to imagine a reason why these might be unsafe, but
failed. I do notice they're all only used in information_schema.Could it just perhaps be that these just missed the verification
process the other functions went through to determine their parallel
safety?
Yes, I think that's it. I went through pg_proc.h, but never looked at
information_schema.sql.
--
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
On 11/24/16 18:13, Robert Haas wrote:
I'm finding hard to imagine a reason why these might be unsafe, but
failed. I do notice they're all only used in information_schema.Could it just perhaps be that these just missed the verification
process the other functions went through to determine their parallel
safety?Yes, I think that's it. I went through pg_proc.h, but never looked at
information_schema.sql.
This hasn't been fixed yet. It's easy to to, but taking a step back,
- Is there any reason an immutable function (that is not lying about it)
should be anything but parallel safe?
- If so, could CREATE FUNCTION default it that way?
- Maybe add a check to opr_sanity to make sure the default set of
functions is configured the way we want?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, 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
On Wed, Apr 5, 2017 at 8:57 AM, Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
On 11/24/16 18:13, Robert Haas wrote:
I'm finding hard to imagine a reason why these might be unsafe, but
failed. I do notice they're all only used in information_schema.Could it just perhaps be that these just missed the verification
process the other functions went through to determine their parallel
safety?Yes, I think that's it. I went through pg_proc.h, but never looked at
information_schema.sql.This hasn't been fixed yet. It's easy to to, but taking a step back,
- Is there any reason an immutable function (that is not lying about it)
should be anything but parallel safe?
It certainly isn't very likely. It's not outright impossible. For
example, imagine a function that does a calculation which is
deterministic given the inputs but which creates and uses temporary
tables in the course of performing the calculation. Because the
function performs writes, it's parallel-unsafe.
- If so, could CREATE FUNCTION default it that way?
This could be done but I'm not sure whether it's wise to make the
default value for one parameter depend on another parameter.
- Maybe add a check to opr_sanity to make sure the default set of
functions is configured the way we want?
That seems like a good idea.
--
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
Robert Haas <robertmhaas@gmail.com> writes:
On Wed, Apr 5, 2017 at 8:57 AM, Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:- Maybe add a check to opr_sanity to make sure the default set of
functions is configured the way we want?
That seems like a good idea.
+1 for that. We could adopt the strategy already used in opr_sanity of
searching for functions having an unexpected combination of these
attributes. If there are any legitimate exceptions, they could be
embedded in the expected output.
I concur that changing the behavior of CREATE FUNCTION seems a bit too
cute.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 4/5/17 09:58, Robert Haas wrote:
- Maybe add a check to opr_sanity to make sure the default set of
functions is configured the way we want?That seems like a good idea.
patch
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachments:
0001-Mark-immutable-functions-in-information-schema-as-pa.patchinvalid/octet-stream; name=0001-Mark-immutable-functions-in-information-schema-as-pa.patchDownload+24-3
On Wed, Apr 5, 2017 at 12:18 PM, Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
On 4/5/17 09:58, Robert Haas wrote:
- Maybe add a check to opr_sanity to make sure the default set of
functions is configured the way we want?That seems like a good idea.
patch
LGTM
--
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
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
On 4/5/17 09:58, Robert Haas wrote:
- Maybe add a check to opr_sanity to make sure the default set of
functions is configured the way we want?
That seems like a good idea.
patch
Looks sane to me, although I wonder if opr_sanity ought to be looking
for any other combinations.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 4/5/17 12:26, Robert Haas wrote:
On Wed, Apr 5, 2017 at 12:18 PM, Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:On 4/5/17 09:58, Robert Haas wrote:
- Maybe add a check to opr_sanity to make sure the default set of
functions is configured the way we want?That seems like a good idea.
patch
LGTM
committed
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, 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