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
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 |