>
> 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
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
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
On Fri, Sep 17, 2021 at 1:13 PM Benedict Holland <
benedict.m.holl...@gmail.com> wrote:
> I don't get why there are so many programming languages out there. C is
> virtually perfect.
>
Oh my. Even its creators didn't believe this, and that was decades ago. Use
after free. Dangling pointers. No
