>
>
> Interesting. Can you nail down the software versions that were in
> use here? That'd be the old PG server version upgraded from, the
> new server version upgraded to, the versions of pg_upgrade and
> pg_dump (these probably should match the new server version, but
> I'm not certain we enfor
Tobias Meyer writes:
> I was able to correlate the transaction ids (xmin) of the duplicate rows in
> pg_largeobject_meta with times stored in another table, and found the
> duplicates were all added on one specific day, while the originals nicely
> spread out over time. I was further able to trace
>
>
>
>> 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 b
>
> 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*
Tobias Meyer writes:
> so I did
> select ctid as tid,oid,lomowner into temp table temp_pgmeta from
> pg_largeobject_metadata;
> select * from ( select count(tid) as cnt,max(tid), min(tid), oid from
> temp_pgmeta group by oid) x where cnt > 1;
> and that gave me 2951857 rows
Yipes. Did you verif
Hi Tom,
thanks for taking a look.
> hmm ... is this a reasonably up-to-date v10?
>
> PostgreSQL 10.18
The latest packaged with Ubuntu 18.04.
> Delete by ctid.
>
> select ctid, oid, * from pg_largeobject_metadata where oid=665238;
> delete from pg_largeobject_metadata where ctid = 'pick one';
>
Tobias Meyer writes:
> Now I see
> select oid,* from pg_largeobject_metadata where oid=665238;
> oid | lomowner | lomacl
> +--+
> 665238 |16123 |
> 665238 |16123 |
> (2 rows)
hmm ... is this a reasonably up-to-date v10?
> Deleting both would be a no-go, as I
Well, it seems we have hit a bug in postgresql 10.
We tried running vacuumlo on a database and it complained at some point
with a message
Failed to remove lo 64985186: ERROR: large object 64985186 does not exist
Removal from database "X" failed at object 26 of 100.
Yet, object 64985186 is
