| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Greg Nancarrow <gregn4422(at)gmail(dot)com>, "tsunakawa(dot)takay(at)fujitsu(dot)com" <tsunakawa(dot)takay(at)fujitsu(dot)com>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: [bug?] Missed parallel safety checks, and wrong parallel safety |
| Date: | 2021-05-04 19:09:05 |
| Message-ID: | CA+TgmoYoisfDs4yw5K0JkoDmd7y60R16XvC+-uzHHFgvCD9-tA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Apr 23, 2021 at 10:53 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> Isn't parallel safety also the C code property?
In my opinion, yes.
> So, isn't it better to disallow changing parallel
> safety for built-in functions?
Superusers can do a lot of DML operations on the system catalogs that
are manifestly unsafe. I think we should really consider locking that
down somehow, but I doubt it makes sense to treat this case separately
from all the others. What do you think will happen if you change
proargtypes?
> Also, if the strict property of built-in functions is fixed
> internally, why we allow users to change it and is that of any help?
One real application of allowing these sorts of changes is letting
users correct things that were done wrong originally without waiting
for a new major release.
--
Robert Haas
EDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavel Stehule | 2021-05-04 19:10:10 | Re: few ideas for pgbench |
| Previous Message | Jeff Davis | 2021-05-04 19:04:12 | Re: MaxOffsetNumber for Table AMs |