Functions Immutable but not parallel safe?
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t35631psql -h localhost -U postgresBuilt from patchset v6 (message #6), July 28, 2026 at 07:23 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t35631_6 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t35631_6 && git checkout t35631_6Patchset v6 (message #6) is on t35631_6
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
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