Date: Wed, 9 Apr 2025 12:04:21 -0500
From: Nathan Bossart <nathandbossart@gmail.com>
To: Jan Wieck <jan@wi3ck.info>
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: Horribly slow pg_upgrade performance with many Large Objects
Message-ID: <Z_aolVLRe8PoPht_@nathan>
References: <4044567.1744128814@sss.pgh.pa.us>
 <CAMT0RQSALxZ2DJbq0b5cy+cvmpVxkawmv7c+qTWYObubZVr+2g@mail.gmail.com>
 <4047312.1744130263@sss.pgh.pa.us>
 <Z_VTucTiS01p-d6z@nathan>
 <4050387.1744132029@sss.pgh.pa.us>
 <Z_VbON4DZn0wPvUN@nathan>
 <4054965.1744134140@sss.pgh.pa.us>
 <Z_VtcQxi_i78-yjg@nathan>
 <CAMT0RQQFZHZvftObnG9OAHE=bOhuVA_ymp6pG+dLfS66o-EGNA@mail.gmail.com>
 <287aef2b-36e8-446c-bd15-bfc8e8272c2f@wi3ck.info>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <287aef2b-36e8-446c-bd15-bfc8e8272c2f@wi3ck.info>
Archived-At: <https://www.postgresql.org/message-id/Z_aolVLRe8PoPht_%40nathan>
Precedence: bulk

On Tue, Apr 08, 2025 at 05:37:50PM -0400, Jan Wieck wrote:
> 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?

I believe commits 74cf7d4 and 959b38d have largely fixed that problem.

-- 
nathan