Re: pg_config wrongly marked as not parallel safe?

Greetings,

* Andres Freund (andres(at)anarazel(dot)de) wrote:
> On 2018-11-26 19:16:00 -0500, Stephen Frost wrote:
> > * Andres Freund (andres(at)anarazel(dot)de) wrote:
> > > On 2018-11-26 19:04:46 -0500, Joe Conway wrote:
> > > > So the correct answer is probably to mark pg_config() stable, but it
> > > > still seems to be parallel safe to me.
> > >
> > > I don't think we should consider immutability to mean anything across
> > > major versions. What'd be helped by doing that? We'd have to rule out
> > > any behaviour change to any immutable function for that to make
> > > sense. Including making an immutable function not immutable anymore.
> >
> > Then we have to require that all indexes built with immutable functions
> > be rebuilt when someone does a pg_upgrade from one major version to the
> > next.
>
> Happened a couple times. The harm from overaggressively removing
> immutability, and thus not even being able to add such indexes and
> obviously worse query plans, seems much bigger than avoiding the need to
> rebuild indexes in some cases.

These two things seem entirely independent in my view, so I'm really not
sure that I'm following what you're getting at.

We have required specific kinds of indexes to be rebuilt across major
version upgrades, yes, but those have almost uniformly been cases where
the index was very rarely used or only used in some corner cases.

I certainly do not believe we should invalidate all indexes built with
immutable functions across major versions upgrades. Perhaps in some
cases when we've decided that an immutable function today should work in
some different way in a new version then we should complain about or
invalidate those indexes, but that's a special case. Taken to an
extreme, you could argue that partial indexes should also be rebuilt on
major version upgrades, in case we decide that 1 is suddently less than
2, but instead of baking that assumption in, let's just deal with those
cases when they come up and write logic into pg_upgrade to detect such
usages and make the user aware of them.

If you feel that immutability is being overaggressively removed from
something, that's fair, but should also be addressed on a case-by-case
basis. In this particular case, I don't see any concern that we're
going to break user's indexes by changing pg_config() to be stable
instead of immutable, and I don't really think we even need to write
logic into pg_upgrade for it- unless it could be generalized to detect
such cases between versions, in which case I'd be all for that in case
we have other such changes. Not sure it's really worth it though, we
don't have that happen all that often.

Thanks!

Stpehen