From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
---|---|
To: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: teach pg_upgrade to handle in-place tablespaces |
Date: | 2025-07-22 00:57:32 |
Message-ID: | aH7h_OH_XOOvbqDA@nathan |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jul 21, 2025 at 08:16:12PM -0400, Corey Huinker wrote:
> Everything here makes sense to me, but I do have one question:
Thanks for reviewing.
> In src/bin/pg_upgrade/info.c
> @@ -616,11 +630,21 @@ process_rel_infos(DbInfo *dbinfo, PGresult *res, void
> *arg)
> + if (inplace)
> + tablespace = psprintf("%s/%s",
> + os_info.running_cluster->pgdata,
> + PQgetvalue(res, relnum, i_spclocation));
> + else
> + tablespace = PQgetvalue(res, relnum, i_spclocation);
>
> I'm sure it's no big deal, but we've already PQgetvalue() fetched that once
> for spcloc, and we're going to fetch it again no matter what the value of
> inplace is. Is there a reason to not reuse spcloc?
I can't think of any reason. Fixed in v4.
--
nathan
Attachment | Content-Type | Size |
---|---|---|
v4-0001-Teach-pg_upgrade-to-handle-in-place-tablespaces.patch | text/plain | 22.4 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2025-07-22 01:29:43 | Re: Support tid range scan in parallel? |
Previous Message | Michael Paquier | 2025-07-22 00:55:41 | Re: Improve error reporting in 027_stream_regress test |