Re: Horribly slow pg_upgrade performance with many Large Objects - Mailing list pgsql-hackers

From Jan Wieck
Subject Re: Horribly slow pg_upgrade performance with many Large Objects
Date
Msg-id 287aef2b-36e8-446c-bd15-bfc8e8272c2f@wi3ck.info
Whole thread Raw
In response to Re: Horribly slow pg_upgrade performance with many Large Objects  (Hannu Krosing <hannuk@google.com>)
Responses Re: Horribly slow pg_upgrade performance with many Large Objects
List pgsql-hackers
On 4/8/25 15:41, Hannu Krosing wrote:
> On Tue, Apr 8, 2025 at 8:39 PM Nathan Bossart <nathandbossart@gmail.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



pgsql-hackers by date:

Previous
From: Jacob Champion
Date:
Subject: Re: [PoC] Federated Authn/z with OAUTHBEARER
Next
From: Tomas Vondra
Date:
Subject: Re: Draft for basic NUMA observability