Horton

Re: Horribly slow pg_upgrade performance with many Large Objects

Jan Wieck <jan@wi3ck.info>

View thread
From: Jan Wieck <jan@wi3ck.info>
To: pgsql-hackers@lists.postgresql.org
Date: 2025-04-08T21:37:50Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. pg_upgrade: Use COPY for large object metadata.

  2. pg_dump: Fix object-type sort priority for large objects.

  3. pg_upgrade: Mention that we preserve database OIDs in a comment.

  4. pg_upgrade: Preserve database OIDs.

  5. Fix pg_upgrade for oid removal.

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