Date: Tue, 8 Apr 2025 13:39:45 -0500
From: Nathan Bossart <nathandbossart@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Hannu Krosing <hannuk@google.com>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Horribly slow pg_upgrade performance with many Large Objects
Message-ID: <Z_VtcQxi_i78-yjg@nathan>
References: <Z_RO37whB1L2LbiD@nathan>
 <CAMT0RQRL08=Si+9V7RW7VKcbo2H7GO6ME3opkS_WHpE8qctBLg@mail.gmail.com>
 <Z_VE4Q4A2nNCX3Ny@nathan>
 <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4054965.1744134140@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/Z_VtcQxi_i78-yjg%40nathan>
Precedence: bulk

On Tue, Apr 08, 2025 at 01:42:20PM -0400, Tom Lane wrote:
> Nathan Bossart <nathandbossart@gmail.com> writes:
>> Unless I'm missing something, we don't seem to have had any dependency
>> handling before commit 12a53c7.  Was that broken before we moved to SQL
>> commands?
> 
> Sounds like it :-(

Huh.  Sure enough, it seems to be lost during an upgrade from 9.6 to 10.

v9.6:

	postgres=# select lo_from_bytea(1234, '1234');
	 lo_from_bytea
	---------------
	          1234
	(1 row)

	postgres=# create role bob;
	CREATE ROLE
	postgres=# grant select on large object 1234 to bob;
	GRANT
	postgres=# drop role bob;
	ERROR:  role "bob" cannot be dropped because some objects depend on it
	DETAIL:  privileges for large object 1234

v10 (upgraded from v9.6):

	postgres=# select lo_get(1234);
	   lo_get
	------------
	 \x31323334
	(1 row)

	postgres=# drop role bob;
	DROP ROLE

If I then try to upgrade that database to v17, it fails like this:

	pg_restore: from TOC entry 2422; 0 0 ACL LARGE OBJECT 1234 nathan
	pg_restore: error: could not execute query: ERROR:  role "16384" does not exist
	Command was: GRANT SELECT ON LARGE OBJECT 1234 TO "16384";

I've also verified that the dependency information is carried over in
upgrades to later versions (AFAICT all the supported ones).

-- 
nathan