Yipes. Did you verify that the TIDs are all distinct?
yes, they were.
A possible theory is that pg_largeobject_metadata_oid_index has been corrupt for a long time, allowing a lot of duplicate entries to be made. However, unless pg_largeobject's pg_largeobject_loid_pn_index is *also* corrupt, you'd think that creation of such duplicates would still be stopped by that unique index. There's something mighty odd here.
That would be a mildly disturbing thought indeed.
Any way to quickly check that without reindexing?
But if those duplicates were inserted during normal operation, that would mean there had been an OID overflow, correct?
And that would also mean we would have to be referencing the same OID in more than one place (different LOs actually), which I could not see in the other tables. Did not check that for all 2.9 million though.
Let me roll back the test instance to before the first vacuumlo run and verify if the index was OK before - will only get to do that on monday though.
