"houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com> writes:
> On Tuesday, June 8, 2021 10:51 PM Robert Haas <robertmhaas@gmail.com>
> wrote:
>> In my opinion, you're basically taking too pure a view of this. We're
>> not trying to create a system that does such a good job checking
>> parallel safety markings that nobody can possibly find a thing that
>> isn't checked no matter how hard they poke around the dark corners of
>> the system. Or at least we shouldn't be trying to do that.
> I think another case that parallel unsafe function could be invoked in
> parallel mode is the TEXT SEARCH TEMPLATE's init_function or
> lexize_function.
Another point worth making in this connection is what I cited earlier
today in ba2c6d6ce:
: ... We could imagine prohibiting SCROLL when
: the query contains volatile functions, but that would be
: expensive to enforce. Moreover, it could break applications
: that work just fine, if they have functions that are in fact
: stable but the user neglected to mark them so. So settle for
: documenting the hazard.
If you break an application that used to work, because the
developer was careless about marking a function PARALLEL SAFE
even though it actually is, I do not think you have made any
friends or improved anyone's life. In fact, you could easily
make things far worse, by encouraging people to mark things
PARALLEL SAFE that are not. (We just had a thread about somebody
marking a function immutable because they wanted effect X of that,
and then whining because they also got effect Y.)
There are specific cases where there's a good reason to worry.
For example, if we assume blindly that domain_in() is parallel
safe, we will have cause to regret that. But I don't find that
to be a reason why we need to lock down everything everywhere.
We need to understand the tradeoffs involved in what we check,
and apply checks that are likely to avoid problems, while not
being too nanny-ish.
regards, tom lane