On 8/29/25 21:03, Peter Geoghegan wrote:
> On Fri, Aug 29, 2025 at 9:10 AM Tomas Vondra <tomas@vondra.me> wrote:
>> Peter, any thoughts on this. Do you think it's reasonable / feasible to
>> push the fix?
>
> I don't feel comfortable pushing that fix today.
>
Understood.
> Honestly, I'm still not sure what to do. My proposal was to just
> remove the totally unused options support function, which is probably
> fine. But since I don't really know why Alexander ever added the
> "options" support function in the first place (I don't even see a
> theoretical benefit), I'm not quite prepared to say that I know that
> it's okay to remove it now.
>
Right. I think removing the "options" is the only feasible solution for
PG18 at this point. Either that or nothing. The other patch is far too
invasive.
As for why the support procedure was added to existing index AMs, I
don't know. I suppose it as mostly for consistency, so that custom
oclasses could opclasses could use that. I have no idea if there are
plausible custom opclasses using this.
I'm not sure how I feel about removing the support proc. It feels pretty
arbitrary and fragile, and IIRC it doesn't even address the perf issue
(add a couple partitions and it'll hit the same issue). It just restores
the "threshold" to where it was for PG17. And it's fragile, because we
have no protections about hitting this glibc-specific behavior again. It
takes one new flag added somewhere, and we'll not even notice it.
So after thinking about this a bit more, and refreshing the context, I
think the right solution for PG18 is to do nothing.
regards
--
Tomas Vondra
