I wrote:
> This is an absolutely horrid mess, of course. The big problem
> is that at this point I have exactly zero confidence that there
> are not other places with the same bug; and it's not apparent
> how to find them.
I took a look at every reference to LargeObjectRelationId and
LargeObjectMetadataRelationId, and indeed found two more bugs
(one very minor, and one only latent, but bugs nonetheless).
I'm not entirely convinced that there are no others, but
this is the best I can do for now.
> There seems little choice but to make the hacky fix in v16,
> but I wonder whether we shouldn't be more ambitious and try
> to fix this permanently in HEAD, by getting rid of the
> discrepancy in which OID to use. ISTM the correct fix
> is to change the ObjectAddress representation of large
> objects to use classid LargeObjectMetadataRelationId.
> Somebody seems to have felt that that would create more
> problems than it solves, but I have to disagree. If we
> stick with the current way, we are going to be hitting
> problems of this ilk forevermore.
I still kind of feel that way, but I realized that making
such a change would be rather unpleasant for pg_dump:
it'd have to cope with pg_depend contents that vary across
versions, and probably do some translation if we'd like
dump archive files to stay consistent. We'd also break
post-create and post-alter hooks, and likely some other
third-party code. So maybe best to leave it alone.
I've pushed fixes for the bugs I was able to find.
regards, tom lane