On Tue, Oct 6, 2026 at 12:51 PM Tom Lane <[email protected]> wrote:
> I went through all the data types that allege equalimage support
> carefully, and found another problem: oidvector is claimed to
> behave this way, but it does not. In particular, btoidvectorcmp
> intentionally pays no attention to the array lower bound field.
Thanks for going to the trouble. I'll prepare a fix for these issues.
> While oidvectors would normally have a lower bound of 0, it's
> not hard at all to make one that doesn't:
> So my first instinct is that we'd better rescind equalimage support
> for oidvector too. But then pg_proc_proname_args_nsp_index and
> perhaps some other system catalog indexes will start failing amcheck
> in existing installations. That'd likely cause enough trouble to
> outweigh the safety argument, especially since I really doubt that
> it's possible to get a nonstandard oidvector value into a catalog
> without doing superuser-y things.
>
> So I'm not quite sure what to do about this. Maybe rescind in
> HEAD/v19, and do nothing in the back branches?
+1. Once we rescind oidvector support for deduplication, amcheck will
reliably flag every affected index's metapage as corrupt -- regardless
of the actual contents of the index. That doesn't seem worth it, all
things considered.
> By the by, I'm not especially happy about the errhint that Noah
> added in 5f27b5f84:
>
> + has_interval_ops
> + ? errhint("This is known of \"interval\" indexes last
> built on a version predating 2023-11.")
> + : 0));
>
> This seems to me to have passed its sell-by date somewhere around
> 2024.
I'll remove that on master in passing. Also, I'll remove the relevant
pg_amproc.dat entries on 19 and master, but leave them alone on the
backbranches (backbranches will have to teach btequalimage and
btvarstrequalimage to disallow deduplication with these unsafe
opclasses).
--
Peter Geoghegan
