Re: Bogus collation version recording in recordMultipleDependencies

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Bogus collation version recording in recordMultipleDependencies
Date: 2021-04-19 20:21:17
Message-ID: 341319.1618863677@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> ... The question
> on my mind is whether reverting the feature and trying again for 15
> could produce anything fundamentally better at a design level, or
> would just fix problems in the analyser code that we could fix right
> now.

Well, as I said, I think what we ought to do is treat any record-accepting
functions/operators as "don't know, better assume it's collation
dependent". What's not clear to me is how that concept could be
shoehorned into the existing design.

> For example, if you think there actually is a potential better
> plan than using pg_depend for this, that'd definitely be good to know
> about.

I really dislike using pg_depend, for a couple of reasons:

* You've broken the invariant that dependencies on pinned objects
are never recorded. Now, some of them exist, for reasons having
nothing to do with the primary goals of pg_depend. If that's not
a sign of bad relational design, I don't know what is. I didn't
look at the code, but I wonder if you didn't have to lobotomize
some error checks in dependency.c because of that. (Perhaps
some sort of special-case representation for the default
collation would help here?)

* pg_depend used to always be all-not-null. Now, most rows in it
will need a nulls bitmap, adding 8 bytes per row (on maxalign=8
hardware) to what had been fairly narrow rows. By my arithmetic
that's 13.3% bloat in what is already one of our largest
catalogs. That's quite unpleasant. (It would actually be
cheaper to store an empty-string refobjversion for non-collation
entries; a single-byte string would fit into the pad space
after deptype, adding nothing to the row width.)

> Hrmph. Yeah. We didn't consider types that change later like this,
> and handling those correctly does seem to warrant some more thought
> and work than we perhaps have time for. My first thought is that we'd
> need to teach it to trigger reanalysis.

That seems like a nonstarter, even before you think about race
conditions.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2021-04-19 20:25:13 Re: Allowing to create LEAKPROOF functions to non-superuser
Previous Message Robert Haas 2021-04-19 19:50:52 Re: pg_amcheck contrib application