public inbox for [email protected]
help / color / mirror / Atom feedFrom: Nathan Bossart <[email protected]>
To: Tom Lane <[email protected]>
Cc: Hannu Krosing <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: Horribly slow pg_upgrade performance with many Large Objects
Date: Tue, 8 Apr 2025 12:22:00 -0500
Message-ID: <Z_VbON4DZn0wPvUN@nathan> (raw)
In-Reply-To: <[email protected]>
References: <CAMT0RQSS-6qLH+zYsOeUbAYhop3wmQTkNmQpo5--QRDUR+qYmQ@mail.gmail.com>
<Z_RO37whB1L2LbiD@nathan>
<CAMT0RQRL08=Si+9V7RW7VKcbo2H7GO6ME3opkS_WHpE8qctBLg@mail.gmail.com>
<Z_VE4Q4A2nNCX3Ny@nathan>
<[email protected]>
<CAMT0RQSALxZ2DJbq0b5cy+cvmpVxkawmv7c+qTWYObubZVr+2g@mail.gmail.com>
<[email protected]>
<Z_VTucTiS01p-d6z@nathan>
<[email protected]>
On Tue, Apr 08, 2025 at 01:07:09PM -0400, Tom Lane wrote:
> Nathan Bossart <[email protected]> writes:
>> I do think it's worth considering going back to copying
>> pg_largobject_metadata's files for upgrades from v16 and newer.
>
> (If we do this) I don't see why we'd need to stop at v16. I'm
> envisioning that we'd use COPY, which will be dealing in the
> text representation of aclitems, and I don't think that's changed
> in a long time. The sort of thing that would break it is changes
> in the set of available/default privilege bits for large objects.
I was thinking of actually reverting commit 12a53c7 for upgrades from v16,
which AFAICT is the last release where any relevant storage formats changed
(aclitem changed in v16). But if COPY gets us pretty close to that and is
less likely to be disrupted by future changes, it could be a better
long-term approach.
> That is, where the dump currently contains something like
>
> SELECT pg_catalog.lo_create('2121');
> ALTER LARGE OBJECT 2121 OWNER TO postgres;
> GRANT ALL ON LARGE OBJECT 2121 TO joe;
>
> we'd have
>
> COPY pg_largeobject_metadata FROM STDIN;
> ...
> 2121 10 {postgres=rw/postgres,joe=rw/postgres}
> ...
>
> and some appropriate COPY data for pg_shdepend too.
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?
--
nathan
view thread (46+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected]
Subject: Re: Horribly slow pg_upgrade performance with many Large Objects
In-Reply-To: <Z_VbON4DZn0wPvUN@nathan>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox