From: Nathan Bossart <nathandbossart@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Hannu Krosing <hannuk@google.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Horribly slow pg_upgrade performance with many Large Objects
Date: Wed, 9 Apr 2025 12:16:44 -0500
Message-ID: <Z_arfJajI7RPt7ZJ@nathan> (raw)
In-Reply-To: <4055696.1744134682@sss.pgh.pa.us>
References: <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>
<CAMT0RQTCxjfK_fU4bBLw0Xv61vUEqP4TfNqYJGRmMqqikPBZ3Q@mail.gmail.com>
<4054389.1744133818@sss.pgh.pa.us>
<Z_VfxnhSJIa6VQJt@nathan>
<4055696.1744134682@sss.pgh.pa.us>
On Tue, Apr 08, 2025 at 01:51:22PM -0400, Tom Lane wrote:
> Nathan Bossart <nathandbossart@gmail.com> writes:
>> On Tue, Apr 08, 2025 at 01:36:58PM -0400, Tom Lane wrote:
>>> Hmm ... one annoying thing for this project is that AFAICS pg_upgrade
>>> does *not* preserve database OIDs, which is problematic for using
>>> COPY to load pg_shdepend rows.
>
>> I think it does; see commit aa01051.
>
> Ah --- I thought I remembered something having been done about that,
> but I failed to find it because I was looking in pg_upgrade not
> pg_dump. Too bad aa01051 didn't update the comment at the top of
> pg_upgrade.c.
I'll apply the attached patch to fix the comment shortly.
--
nathan
Attachments:v1-0001-Mention-that-we-preserve-database-OIDs-in-pg_upgr.patch (text/plain, 1.0K) download
From 0ca95279bde8f3ce069a749253eba7c04988003e Mon Sep 17 00:00:00 2001
From: Nathan Bossart <nathan@postgresql.org>
Date: Wed, 9 Apr 2025 12:12:27 -0500
Subject: [PATCH v1 1/1] Mention that we preserve database OIDs in pg_upgrade.c
comment.
Oversight in commit aa01051418.
Reported-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/4055696.1744134682%40sss.pgh.pa.us
---
src/bin/pg_upgrade/pg_upgrade.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/bin/pg_upgrade/pg_upgrade.c b/src/bin/pg_upgrade/pg_upgrade.cindex 72b5a5fde5a..d9db48dba0d 100644--- a/src/bin/pg_upgrade/pg_upgrade.c+++ b/src/bin/pg_upgrade/pg_upgrade.c@@ -32,6 +32,9 @@
* We control all assignments of pg_authid.oid for historical reasons (the
* oids used to be stored in pg_largeobject_metadata, which is now copied via
* SQL commands), that might change at some point in the future.
+ *+ * We control all assignments of pg_database.oid because we want the directory+ * names to match between the old and new cluster.
*/
--
2.39.5 (Apple Git-154)
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: pgsql-hackers@postgresql.org
Cc: nathandbossart@gmail.com, tgl@sss.pgh.pa.us, hannuk@google.com, pgsql-hackers@lists.postgresql.org
Subject: Re: Horribly slow pg_upgrade performance with many Large Objects
In-Reply-To: <Z_arfJajI7RPt7ZJ@nathan>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox