Re: pg_config wrongly marked as not parallel safe? - Mailing list pgsql-hackers

Stephen Frost <sfrost@snowman.net> writes:
> We, today, have a baked in assumption that any function marked as
> immutable will remain immutable across all major versions that we allow
> indexes to be retained through, which is all of them since about 8.3 at
> this point.

That's the ideal situation, yes.

> I don't agree that we can simply declare that all functional and partial
> indexes have to be rebuilt between every major version upgrade, which is
> the alternative.

I agree that that's quite impractical, but ...

> There really isn't another option- either we're
> extremely careful and take immutability of functions seriously and make
> sure to preserve behavior, and therefore indexes, across major versions,
> or we don't and we require indexes to be rebuilt.

... I find that position to be uselessly simplistic.  There's a huge range
of gray area here, and all the interesting cases fall in the gray area.
For a couple of quick examples:

* What about bugs?  Should I not have fixed cbdb8b4c0 (wrong answer for
ftoi4(INT_MAX)) on the grounds that doing so might break somebody's index?

* A lot of relevant behavior isn't as much under our control as one
might wish.  For example, recompiling with a new compiler, or different
optimization options, might affect the behavior of roundoff-sensitive
floating point calculations.  It's not practical to forbid people from
doing that, nor to promise that it won't change results.

At the same time, restricting the "immutable" label to things that
seem very unlikely to be affected by any such considerations isn't
a useful position for us to take.  Functional indexes are just too
useful, and the cases where they actually fail are not that frequent.

Certainly, if we make a change that we know is likely to require people to
reindex affected indexes, that should be documented in the release notes.
But I think it's pointless to imagine that we can achieve perfection in
identifying trouble cases, or even to spend significantly more resources
than we do now on trying.  I've not seen many field trouble reports that
seem to trace back to such issues.

But to bring this back to the thread title: pg_config is *intended*
to change results across versions, or even just rebuilds.  There's
no definition of "immutable" under which it should qualify.  At the
same time, there's no obvious use-case for indexing its result, so
that not marking it as immutable doesn't seem to have much downside.

A contrary case that's worth remarking on is to_tsvector and related
functions, which are marked immutable so that they can be indexed,
even though we know darn well that their results depend on changeable
text search configuration parameters.  I remember complaining about
this when the feature was first put in.  Oleg and Teodor responded
that it wouldn't cause big problems, and they were right (so far as
I've heard about).  That's partly because a change in to_tsvector's
behavior might cause text searches to fail to match, but it won't
result in index corruption or anything like that.  So it's important
to consider context and potential bad effects when deciding what we
should allow here.

Maybe the tl;dr version of that is that the immutable/stable/volatile
division is too simplistic and we need to refine it.  But I don't
know what a better design would look like.  Also, I suspect that real
users are already hard put to it to label their functions correctly
in the three-way regime.  Making it more complicated might make things
actively worse, if it increases the odds of functions being mislabeled.

            regards, tom lane