Re: Horribly slow pg_upgrade performance with many Large Objects

From: Jan Wieck <jan(at)wi3ck(dot)info>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Horribly slow pg_upgrade performance with many Large Objects
Date: 2025-04-08 21:37:50
Message-ID: 287aef2b-36e8-446c-bd15-bfc8e8272c2f@wi3ck.info
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 4/8/25 15:41, Hannu Krosing wrote:
> On Tue, Apr 8, 2025 at 8:39 PM Nathan Bossart <nathandbossart(at)gmail(dot)com> wrote:
>>
> ...
>>
>> I've also verified that the dependency information is carried over in
>> upgrades to later versions (AFAICT all the supported ones).
>
> If I remember correctly the change to not copying
> pg_largeobject_metadata data file but instead moving LOs as part of
> schema was done in v12 when oid,, which had been a system column in
> v11, became a user column, so upgrade to v11 is likely also missing
> the dependencies
>
>

I remember an incident where large amounts of LOs ran pg_upgrade into a
transaction-ID wrap around because the restore part would create
individual single statement transactions per LO to create, then change
permissions and ownership and finally fill in the data. Could that be
related here?

Regards, Jan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2025-04-08 22:47:59 Re: Draft for basic NUMA observability
Previous Message Jacob Champion 2025-04-08 21:32:09 Re: [PoC] Federated Authn/z with OAUTHBEARER